Analisi e risposta alle minacce

Questo argomento offre indicazioni informali per aiutarti a indagare e a rispondere alle e utilizzare risorse aggiuntive per aggiungere contesto ai risultati di Security Command Center. Seguendo questa procedura puoi capire cosa è successo durante una potenziale attaccare e sviluppare possibili risposte per le risorse interessate.

Non è garantito che le tecniche illustrate in questa pagina siano efficaci contro qualsiasi minacce precedenti, attuali o future che devi 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 i ruoli IAM (Identity and Access Management) necessari, devi disporre di ruoli adeguati risultati e log e modificare le risorse Google Cloud. Se riscontri l'accesso in Security Command Center, chiedi assistenza all'amministratore e verifica Controllo dell'accesso per scoprire di più sui ruoli. risolvere la risorsa leggere la documentazione relativa ai prodotti interessati.

Comprensione dei risultati delle minacce

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

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

I risultati vengono scritti in Security Command Center. Se attivi Nel livello Premium di Security Command Center a livello di organizzazione, puoi anche configurare i risultati da scrivere in Cloud Logging.

Esame dei risultati

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

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

   Vai a Risultati

2. Se necessario, seleziona il progetto, la cartella o dell'organizzazione.

   

3. Nella sezione Filtri rapidi, fai clic sul filtro appropriato da visualizzare il risultato di cui hai bisogno nella tabella Risultati della query dei 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 completata con i risultati per l'origine selezionata.

4. Per visualizzare i dettagli di un risultato specifico, fai clic sul suo nome sotto 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 la modalità 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:

• ATTACCA ATTACCO del framework di destinazione. 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 delle 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 falsi positivi permanenti 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 un risultato o modificarne lo stato, consulta i seguenti argomenti:

• Disattiva risultati.
• Modificare lo stato di un risultato

Risposte di Event Threat Detection

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

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

Evasion: Access from Anonymizing Proxy

L'accesso anomalo da un proxy anonimo viene rilevato esaminando Cloud Audit Logs per le modifiche ai servizi Google Cloud che hanno avuto origine dalla indirizzi IP proxy, come gli indirizzi IP 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 le elencati i valori 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Defense Evasion: Breakglass Workload Deployment Created

La metrica Breakglass Workload Deployment Created viene rilevata esaminando Cloud Audit Logs per vedere se esistono deployment per 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 dei risultati

1. Apri il risultato Defense Evasion: Breakglass Workload Deployment Created, come indicato in Revisione dei 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 principale: l'account che ha eseguito la modifica.
     • Nome metodo: il metodo chiamato.
     • Pod Kubernetes: nome del pod e spazio dei nomi.
   • Risorsa interessata, in particolare il seguente campo:
     • Nome visualizzato della risorsa: lo spazio dei nomi GKE in cui in cui è stato eseguito il deployment.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega 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 il una richiesta di firma del certificato specifica.

3. 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Elusione 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 il MITRE ricerca.

Defense Evasion: Breakglass Workload Deployment Updated

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

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli 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 il una richiesta di firma del certificato specifica.

3. 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Elusione 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 il MITRE ricerca.

Defense Evasion: Modify VPC Service Control

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

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

• Un progetto viene rimosso da un perimetro
• Un criterio relativo al livello di accesso viene aggiunto a un perimetro esistente
• Uno o più servizi vengono aggiunti all'elenco di 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. Il riquadro per il risultato dei dettagli, in cui è visualizzata la scheda Riepilogo.

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

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

3. Fai clic sulla scheda JSON.

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

   • sourceProperties
     • properties
       • name: il nome del perimetro Controlli di servizio VPC che è stato modificato
       • policyLink: il link al criterio di accesso che controlla il perimetro
       • delta: le modifiche, REMOVE o ADD, a un perimetro che ha ridotto la sua protezione
       • restricted_resources: i progetti che seguono le restrizioni di su questo perimetro. La protezione viene ridotta se rimuovi un progetto
       • restricted_services: i servizi a cui è vietata l'esecuzione dalle restrizioni di questo perimetro. La protezione viene ridotta se rimuovi un servizio limitato
       • allowed_services: i servizi che possono essere eseguiti in base a questa limitazioni del perimetro. La protezione viene 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: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: evasione della difesa: modifica del processo di autenticazione.
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 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 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 di Gestore contesto accesso sull'entità che ha modificato il perimetro finché l'indagine completata.
• Analizzare come sono state utilizzate le protezioni ridotte. Ad esempio, se "API BigQuery Data Transfer Service" attivato o aggiunto come servizio consentito, controlla chi ha iniziato a usare il servizio e cosa sta trasferendo.

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

1. Apri il risultato Discovery: Can get sensitive Kubernetes object check come di cui alla sezione Analisi dei risultati.

2. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di seguenti campi:

   • Nella sezione Che cosa è stato rilevato:
     • Revisioni degli accessi Kubernetes: informazioni richieste per la revisione degli accessi, in base alla SelfSubjectAccessReview e la risorsa k8s.
     • 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 con i dettagli del risultato, fai clic sull'icona a forma di Link URI Cloud Logging per aprire Esplora log.

2. Nella pagina visualizzata, controlla se ci sono altre azioni intraprese dall'entità utilizzando i seguenti filtri:

   • resource.labels.cluster_name="CLUSTER_NAME"

   • protoPayload.authenticationInfo.principalEmail="PRINCIPAL_EMAIL"

     Sostituisci quanto segue:

   • CLUSTER_NAME: il valore annotato nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Scoperta
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 annotato nella riga Email entità nella trovare i dettagli non è un account di servizio, contattare il proprietario dell'account per verificare se il legittimo proprietario ha condotto l'azione.

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

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

Exfiltration: BigQuery Data Exfiltration

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

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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 secondaria. exfil_to_external_table o LOW per la regola secondaria vpc_perimeter_violation,
     • Email principale: l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sulle tabelle da cui i dati è stato esfiltrato.
     • Target di esfiltrazione: dettagli sulle tabelle in cui sono state esfiltrate sono stati archiviati.
   • Risorsa interessata:
     • Nome completo risorsa: il nome completo della risorsa del progetto, una cartella o un'organizzazione da cui sono stati esfiltrati i dati.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
     • Chronicle: link a Google SecOps.

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

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

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

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

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

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

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

4. Nella tabella, sotto categoria, fai clic su un Exfiltration: BigQuery Data Exfiltration risultato. Il riquadro dei dettagli per il risultato si apre.

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 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 ai job BigQuery utilizzando i seguenti filtri:

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

Passaggio 5: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: 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 lo stesso tipo di risultato nella 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 risultati.

• Contatta il proprietario del progetto con dati esfiltrati.
• Valuta la possibilità di revocare le autorizzazioni per userEmail fino al termine dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi all'entità interessata Set di dati BigQuery (exfiltration.sources e exfiltration.targets).
• 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 conservazione dei costi di Sensitive Data Protection sotto controllo.
• 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: 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 all'esterno della tua organizzazione.
• Una risorsa viene salvata in un bucket Cloud Storage accessibile pubblicamente di proprietà della tua organizzazione.

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

2. Nella scheda Riepilogo del riquadro dei dettagli 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 i dati è stato esfiltrato.
     • Target di esfiltrazione: dettagli sulle tabelle in cui sono state esfiltrate sono stati archiviati.
   • Risorsa interessata:
     • Nome completo risorsa: il nome della risorsa BigQuery. risorsa i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene il set di dati BigQuery di origine.
   • Link correlati:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

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

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 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 ai job BigQuery utilizzando 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 lo stesso tipo di risultato nella stessa istanza e 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 l'entità elencata nella riga Email entità nella Riepilogo dei dettagli dei risultati 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 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 conservazione dei costi di Sensitive Data Protection sotto controllo.
• Per limitare l'accesso all'API BigQuery, utilizza Controlli di servizio VPC.
• Se sei il proprietario del bucket, valuta la possibilità di revocarlo come pubblico autorizzazioni di accesso.
• 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 dei risultati

1. Apri un risultato di Exfiltration: BigQuery Data to Google Drive, come di cui alla sezione Analisi dei risultati.

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

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

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

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

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

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

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. Trova i log delle attività di amministrazione relativi ai job BigQuery utilizzando i seguenti filtri:
   • protoPayload.methodName="Jobservice.insert"
   • protoPayload.methodName="google.cloud.bigquery.v2.JobService.InsertJob"

Passaggio 4: ricerca 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 lo stesso tipo di risultato nella stessa istanza e 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 nel campo access.principalEmail fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi all'entità interessata 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 conservazione dei costi di Sensitive Data Protection sotto controllo.
• 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 istanza Cloud SQL.

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Exfiltration: Cloud SQL Data Exfiltration, 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:
     • Email principale : l'account utilizzato per esfiltrare i dati.
     • Origini di esfiltrazione: dettagli sull'API Cloud SQL i cui dati sono stati esfiltrati.
     • Destinazioni di esfiltrazione: dettagli sul Cloud Storage nel bucket in cui sono stati esportati i dati.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa Cloud SQL i cui dati sono stati esfiltrati.
     • Nome completo del progetto: il progetto Google Cloud che contiene i dati Cloud SQL di origine.
   • Link correlati, tra cui:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

3. Fai clic sulla scheda JSON.

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

   • sourceProperties:
     • evidence:
     • sourceLogId:
       • projectId: il progetto Google Cloud che contiene l'istanza Cloud SQL di origine.
     • properties
     • bucketAccess: se il bucket Cloud Storage è pubblico 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 dei risultati (dal Passaggio 1).

3. Nella pagina visualizzata, inserisci l'indirizzo email nella casella Filtro nella pagina visualizzata. elencata nella riga Email principale nella scheda Riepilogo dell' dei risultati (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: 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. descritta nel Passaggio 1). Correlati 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 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 access.principalEmail fino al termine dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi alla delle 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 log di controllo per determinare se i dati dal backup sono stati ripristinati all'esterno dell'organizzazione o del progetto. Tutti Sono supportati i tipi di backup e istanza Cloud SQL.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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.
     • Destinazioni di esfiltrazione: dettagli sull'istanza Cloud SQL in cui sono stati ripristinati i dati di backup.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa del backup che è 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 MITRE ATT&CK.
   • Risultati correlati: collega a eventuali risultati correlati.

4. Fai clic sulla scheda JSON.

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

   • resource:
     • parent_name: il nome della risorsa 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 su il link nell'URI Cloud Logging (da Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.

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. (da 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 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 l'entità elencato nella riga Email principale della scheda Riepilogo dei dettagli dei risultati fino al completamento dell'indagine.
• Per interrompere un'ulteriore esfiltrazione, aggiungi criteri IAM restrittivi alla delle 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 Motore per suggerimenti.

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

1. Apri Exfiltration: Cloud SQL Over-Privileged Grant come indicato in Revisione dei risultati.

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

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

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

Passaggio 2: rivedi i privilegi del database

1. Connettiti al database PostgreSQL.
2. 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. Usa il metacomando \df e controllare quali privilegi sono assegnati per funzioni o procedure database elencato in Nome visualizzato del database (da 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 PostgreSQL pgaudit, che registrano query eseguite sul database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi 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 autorizzazioni dei beneficiari (da Beneficiari database Passaggio 1.

Initial Access: Database Superuser Writes to User Tables

Rileva quando l'account super user del database Cloud SQL (postgres) per PostgreSQL e root per MySQL) scrive sull'utente tabelle. 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 super user scrive in una tabella utente, potrebbe indicano che un aggressore ha aumentato i privilegi o ha compromesso predefinito e sta modificando i dati. Potrebbe anche indicare normale, pratiche non sicure.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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 risultato, esamina le informazioni nelle seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato database: il nome del database nella Istanza Cloud SQL PostgreSQL o MySQL interessata.
     • Nome utente database: il super user.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

Passaggio 2: controlla i log

1. Nella console Google Cloud, vai a Esplora log facendo clic su il link in cloudLoggingQueryURI (dal Passaggio 1). La pagina Esplora log include tutti i log relativi ai di Cloud SQL.
2. Controlla i log per i log pgaudit PostgreSQL o l'audit di Cloud SQL per MySQL contenenti le query eseguite dal super user, usando i seguenti filtri:
   • protoPayload.request.user="SUPERUSER"

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: 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.

• Controlla gli utenti autorizzati a connettersi al database.

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

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

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

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

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

    • Per PostgreSQL, consulta Concedi (comando)
    • Per MySQL, consulta Controllo 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

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 generalmente 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 è necessaria. Se l'associazione non è necessaria, rimuovila. Per ulteriori informazioni vedi il messaggio di log per questo risultato.

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

Initial Access: GKE resource modified anonymously from the internet

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

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

Questi utenti e gruppi sono generalmente 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 è necessaria. Se l'associazione non è necessaria, rimuovila. Per ulteriori 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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

2. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.

   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 entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 e collaborare con i proprietari delle applicazioni 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 Motore per suggerimenti.

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 viene considerata inattiva se è rimasta inattiva per più di 180 giorni.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

2. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.

   Nella sezione Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

1. 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 risultati.

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Annulla la convalida della chiave dell'account di servizio appena creata nel Pagina Account di servizio.
• 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 e collaborare con i proprietari delle applicazioni 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 dall'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM motore per suggerimenti.

Initial Access: Leaked Service Account Key Used

Rileva gli eventi in cui una chiave dell'account di servizio divulgata viene utilizzata per autenticare un'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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

2. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.

   Nella sezione Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: controlla i log

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

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

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

   Sostituisci PRINCIPAL_EMAIL con il valore che hai annotato nella Campo Email entità nei dettagli del risultato. Sostituisci SERVICE_ACCOUNT_KEY_NAME con il valore che hai annotato in Nel campo Nome chiave account di servizio nei dettagli del risultato.

Passaggio 3: implementa la risposta

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

• Revocare immediatamente la chiave dell'account di servizio Pagina Account di servizio.
• Rimuovi la pagina web o il repository GitHub in cui è pubblicata la chiave dell'account di servizio.
• Potresti eliminare l'account di servizio compromesso.
• Ruota ed elimina tutte le chiavi di accesso degli account di servizio per il progetto potenzialmente compromesso. Dopo il giorno 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 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 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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   Nella sezione Che cosa è stato rilevato:

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

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

   • properties.failedActions: gli errori relativi ad autorizzazioni negate che si sono verificati. Per ogni voce, i dettagli includono il nome del servizio, il nome del metodo numero di tentativi non riusciti e l'ora in cui si è verificato l'ultimo errore. Vengono visualizzate al massimo 10 voci.

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

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

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

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

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: 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à. Conferma se l'azione è stata eseguita dal legittimo proprietario.
• Elimina le risorse di progetto create da quell'account, ad esempio quelle sconosciute Istanze Compute Engine, snapshot, account di servizio, utenti IAM e così via.
• Contatta il proprietario del progetto con l'account ed eventualmente eliminarlo o disattivarlo l'account.

Brute Force: SSH

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

Passaggio 1: esamina i dettagli dei risultati

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

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

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

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

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

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

3. Fai clic sulla scheda JSON.

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

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

Passaggio 2: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indagare sulle minacce e orientarsi tra 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 ai risultati

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

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

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

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

5. Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su 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 visualizzata, trova i log di flusso VPC correlati all'IP indicato nella riga Email entità nella sezione Scheda Riepilogo dei dettagli dei risultati utilizzando il seguente filtro:
   • logName="projects/projectId/logs/syslog"
   • labels."compute.googleapis.com/resource_name"="vmName"

Passaggio 5: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per 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 risultati.

• Contatta il proprietario del progetto a cui è stato eseguito il tentativo di forza bruta riuscito.
• Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. Per facilitare il rilevamento e la rimozione, utilizza un sistema di rilevamento degli endpoint e di risposta alle domande.
• Valuta la possibilità di disabilitare l'accesso SSH alla VM. Per informazioni sulla disabilitazione delle chiavi SSH, consulta Limitare le chiavi SSH da delle VM. Questo passaggio potrebbe interrompere l'accesso autorizzato alla VM, quindi considera le esigenze della tua organizzazione prima di procedere.
• Usa l'autenticazione SSH soltanto con indirizzi autorizzati chiave.
• Blocca gli indirizzi IP dannosi aggiornando il firewall oppure utilizzando Google Cloud Armor. Puoi attivare Google Cloud Armor in Security Command Center integrato Servizi . A seconda della quantità di informazioni, i costi di Google Cloud Armor possono essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.

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

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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

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

Passaggio 2: esamina i membri del gruppo

1. Vai a Google Gruppi.

   Vai a Google Gruppi

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

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

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

   Per rimuovere i membri, devi essere un amministratore di Google Workspace oppure devi essere stato assegnato Con il 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 verificare la presenza di modifiche all'appartenenza ai gruppi Google utilizzando i seguenti filtri:

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

Passaggio 4: ricerca i metodi di attacco e di risposta

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

Credential Access: Privileged Group Opened To Public

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

Rileva quando un gruppo Google con privilegi (un gruppo a cui sono stati concessi ruoli sensibili o autorizzazioni) è diventano accessibili al pubblico. Per rispondere a questo risultato, le seguenti:

Passaggio 1: esamina i dettagli dei risultati

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

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

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

Passaggio 2: esamina le impostazioni di accesso ai gruppi

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

   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 quindi, in Chi può iscriversi al gruppo, rivedere l'impostazione di partecipazione del gruppo.

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

Passaggio 3: controlla i log

1. Nella scheda Riepilogo del riquadro 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 la presenza di modifiche alle impostazioni del gruppo Google utilizzando i seguenti filtri:

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

Passaggio 4: ricerca i metodi di attacco e di risposta

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

Credential Access: Secrets Accessed in Kubernetes Namespace

Rileva quando un pod default Account di servizio Kubernetes è 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 la concessione di autorizzazioni o ruoli sensibili a un Gruppo Google con membri esterni. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
   1. Fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente i seguenti campi.
   • groupName: il gruppo Google in cui sono state apportate le modifiche
   • bindingDeltas: i ruoli sensibili appena concessi a questo gruppo.

Passaggio 2: esamina le autorizzazioni del gruppo

1. Vai alla pagina IAM nella console Google Cloud.

   Vai a IAM

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

3. Esamina i ruoli sensibili concessi al gruppo.

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

   Devi disporre di autorizzazioni specifiche per gestire i ruoli nella tua organizzazione o nel tuo progetto. Per Per saperne di più, consulta 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 verificare la presenza di modifiche alle impostazioni del gruppo Google utilizzando i seguenti filtri:

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

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi.
2. Per determinare se sono necessarie ulteriori 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 Cloud DNS log per le connessioni a indirizzi IP e domini di comando e controllo noti. A rispondi a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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: il sospetto indirizzo IP del cryptomining.
     • Porta di origine: la porta di origine della connessione, se disponibile.
     • IP di destinazione: l'indirizzo IP di destinazione.
     • Porta di destinazione: la porta di destinazione della connessione, se 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 le proprietà e annota i valori di progetto e istanza nella campo seguente:

   • instanceDetails: prendi nota sia dell'ID progetto sia del nome del di Compute Engine. Vengono visualizzati l'ID progetto e il nome dell'istanza 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 properties_project_id.

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

4. Fai clic sull'istanza VM che corrisponde a properties_sourceInstance. Indaga l'istanza potenzialmente compromessa per verificare la presenza di malware.

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

Passaggio 3: controlla i log

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

   Vai a Esplora log

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

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

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Compromissione delle risorse.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con 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 un sistema di rilevamento degli endpoint e di risposta alle domande.
• 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 abilita Google Cloud Armor in Security Command Center Integrated Servizi . A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.

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

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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
   • Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.

   • Nel file JSON, tieni presente i seguenti campi.

   • properties

     • loadBalancerName: il nome del bilanciatore del carico che ha ricevuto la ricerca JNDI
     • requestUrl: l'URL della richiesta HTTP. Se presente, contiene una ricerca JNDI.
     • requestUserAgent: lo user agent che ha inviato la richiesta HTTP. Se presente, contiene una ricerca JNDI.
     • refererUrl: l'URL della pagina che ha inviato la richiesta HTTP. Se 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 visualizzata, verifica la presenza di token di stringa nei campi httpRequest. come ${jndi:ldap://, che potrebbero indicare possibili tentativi di sfruttamento.

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

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: 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 lo stesso tipo di risultato la stessa istanza e la 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 risultati.

• 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, vedi Regola WAF di Google Cloud Armor per contribuire a mitigare la vulnerabilità di Apache Log4j.

Active Scan: Log4j Vulnerable to RCE

Gli scanner di vulnerabilità Log4j supportati inseriscono ricerche JNDI offuscate in HTTP parametri, URL e campi di testo con callback ai domini controllati scanner. Questo risultato viene generato quando eseguono query DNS per i domini non offuscati disponibili. Queste query si verificano solo se una ricerca JNDI ha avuto esito positivo, indicando è presente una vulnerabilità Log4j attiva. Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Active Scan: Log4j Vulnerable to RCE, come indicato in 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, in particolare il seguente campo:
     • Nome completo risorsa: nome completo della risorsa Istanza di Compute Engine vulnerabile all'RCE di Log4j.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

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

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 visualizzata, verifica la presenza di token di stringa nei campi httpRequest. come ${jndi:ldap://, che potrebbero indicare possibili tentativi di sfruttamento.

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

Passaggio 3: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Sfruttamento di Servizi remoti.
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 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 4: implementa la risposta

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

• Esegui l'upgrade all'ultima versione di Log4j2.
• Segui i suggerimenti di Google Cloud per indagare e rispondere 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, 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 risultato, le seguenti:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di account_has_leaked_credentials, come indicato in Revisione dei dettagli dei risultati. 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 la risorsa potenzialmente divulgata credenziali dell'account
   • URL: il link al repository GitHub

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

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

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

   Vai a IAM

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

3. Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. 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 risultato: Account validi: account cloud.
2. Esamina i risultati correlati facendo clic sul link in relatedFindingURI. I risultati correlati sono lo stesso tipo di risultato e la stessa istanza e rete.
3. Per sviluppare un piano di risposta, combina i risultati 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 credenziali divulgate.
• Valuta la possibilità di eliminare l'account di servizio compromesso, esegui la rotazione ed eliminalo 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. Prima di procedere, il team di sicurezza deve identificare tutte le risorse interessate e collaborare con i proprietari delle risorse per garantire la continuità aziendale.
• Collabora con il 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 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.
• Apri il link URL ed elimina le credenziali divulgate. Raccogli di più informazioni sull'account compromesso e contattare il proprietario.

Malware

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

I passaggi seguenti spiegano come indagare e per rispondere ai risultati basati sull'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 seguenti utilizzano Malware: Bad IP risultato, 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:
     • Dominio indicatore: per Bad domain risultati, il dominio che ha attivato il risultato.
     • IP indicatore: per Bad IP risultati, l'indirizzo IP che ha attivato il risultato.
     • IP di origine: per i risultati Bad IP, un comando malware noto e di controllo dell'indirizzo IP.
     • Porta di origine: per Bad IP risultati, la porta di origine della connessione.
     • IP di destinazione: per Bad IP risultati, l'indirizzo IP di destinazione del malware.
     • Porta di destinazione: per Bad IP risultati, la porta di destinazione della connessione.
     • Protocollo: per Bad IP risultati, il 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
     • Chronicle: link a Google SecOps.
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

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

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

Passaggio 2: esamina in Google Security Operations

Puoi utilizzare Google Security Operations per esaminare il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indagare sulle minacce e orientarsi tra 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 ai risultati

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

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

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

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

5. Nella sezione Link correlati del riquadro dei dettagli del risultato, fai clic su 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 indirizzo IP
• Analisi di una risorsa

Passaggio 3: controlla le autorizzazioni e le impostazioni

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

   Vai alla Dashboard

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

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

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

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

Passaggio 4: controlla i log

1. Nella scheda Riepilogo del riquadro 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 selezionando il progetto in elenco nel mese di projectId.
     • SOURCE_IP con l'indirizzo IP indicato su alla riga IP di origine nella scheda Riepilogo dei dettagli del risultato.

Passaggio 5: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Dynamic Risoluzione e Comando e controllo.
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 lo stesso tipo di risultato e la stessa istanza e rete.
3. Controlla gli URL e i domini segnalati 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.
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 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 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 abilita Google Cloud Armor in Security Command Center Integrated Servizi . A seconda del volume di dati, i costi di Google Cloud Armor essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.
• 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 avviare un rifiuto di servizio (DoS) analizzando i log di flusso VPC. Per rispondere ricerca, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Malware: Outgoing DoS 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
     • IP di origine: l'indirizzo IP di origine dell'attività DoS.
     • Porta di origine: la porta di origine della connessione.
     • IP di destinazione: l'indirizzo IP di destinazione dell'attività DoS.
     • Porta di destinazione: la porta di destinazione della connessione.
   • Risorsa interessata
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente i seguenti campi.
   • sourceInstanceDetails: l'istanza VM di Compute Engine interessata

Passaggio 2: controlla le autorizzazioni e le impostazioni

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

   Vai alla Dashboard

2. Seleziona il progetto specificato sourceInstanceDetails.

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

4. Fai clic sull'istanza VM che corrisponde al nome e alla zona dell'istanza 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 visualizzata, trova i log di flusso VPC correlati all'IP indirizzo IP in srcIP utilizzando il seguente filtro:

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

     Sostituisci quanto segue:

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

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: denial of service di rete.
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 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 5: implementa la risposta

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

• Contatta il proprietario del progetto che sta riscontrando traffico DoS in uscita.
• Esamina l'istanza potenzialmente compromessa e rimuovi quelle rilevate malware. 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 abilita Google Cloud Armor in Security Command Center Integrated Servizi . A seconda del volume di dati, i costi di Google Cloud Armor possono essere significativo. Consulta la guida ai prezzi di Google Cloud Armor per ulteriori informazioni.
• Per controllare l'accesso e l'utilizzo delle immagini VM, utilizza Shielded VM e Trusted IAM delle immagini .

Persistence: IAM Anomalous Grant

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

Di seguito sono riportati alcuni esempi di concessioni anomale:

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

Il risultato IAM Anomalous Grant è 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 sulla regola secondaria. Ogni regola secondaria potrebbe richiedere una risposta diversa.

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

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

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Persistence: IAM Anomalous Grant 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:
     • Email principale: l'indirizzo email dell'account utente o di servizio che a cui è stato assegnato il ruolo.

   • Risorsa interessata

   • Link correlati, in particolare i seguenti campi:

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

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

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

   • detectionCategory:
     • subRuleName: informazioni più specifiche sul tipo di si è verificata una concessione anomala. La regola secondaria determina la gravità classificazione 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 il problema. ricerca. Google SecOps è un servizio Google Cloud che ti consente indagare sulle minacce e orientarsi tra le entità correlate in un sequenza temporale. Google SecOps arricchisce i dati dei risultati, consentendoti di identificare indicatori di interesse e semplificare le indagini.

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

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

   Vai ai risultati

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

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

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

4. Nella tabella, sotto category, fai clic su un Persistence: IAM Anomalous Grant risultato. Il riquadro dei dettagli per si apre 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:

• Analisi di un utente
• Analisi di una risorsa

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

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
2. Esamina i risultati correlati facendo clic sul link 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 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 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 Motore per suggerimenti.

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 risultato, l'account di servizio inattivo è risorsa e un account di servizio è considerato inattivo se ha sono stati inattivi per più di 180 giorni.

Per rispondere a questo risultato, procedi nel seguente modo:

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 dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.

   Nella sezione Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

1. 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 risultato, nella sezione Link correlati Fai clic sul link URI Cloud Logging per aprire Esplora log.

Passaggio 4: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Rimuovi il ruolo di rappresentazione appena concesso dal membro di destinazione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 e collaborare con i proprietari delle applicazioni 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 dall'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM motore per suggerimenti.

Persistence: Unmanaged Account Granted Sensitive Role

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 dipendente corrispondente ha lasciato l'azienda, l'amministratore non può eliminare l'account. Di conseguenza, la concessione di ruoli sensibili agli account non gestiti crea una potenziale rischi per la sicurezza dell'organizzazione.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

2. Nei dettagli dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.

   Nella sezione Che cosa è stato rilevato:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: controlla i log

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

Passaggio 4: implementa la risposta

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

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

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

Passaggio 1: esamina i dettagli dei risultati

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

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

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Persistence: New Geography

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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Persistence: New Geography, come indicato in Esaminando 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:
  • Email principale: l'account utente potenzialmente compromesso.
• Risorsa interessata, in particolare i seguenti campi:
  • Nome completo del progetto: il progetto che contiene la funzione account utente compromesso.
• Link correlati, in particolare i seguenti campi:
  • URI Cloud Logging: link alle voci di Logging.
  • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
  • Risultati correlati: collega a eventuali risultati correlati.

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

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

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

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

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

   Vai a IAM

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

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

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: Account validi: account cloud.
2. Per sviluppare un piano di risposta, combina i risultati 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 l'account compromesso.
• Esamina i anomalousLocation, typicalGeolocations e notSeenInLast per verificare se l'accesso è anomalo e se l'account è stato è 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 Limitazione delle località delle risorse.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza IAM Motore per suggerimenti.

Persistence: New User Agent

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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Persistence: New User Agent, 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:
     • Email principale: l'account di servizio potenzialmente compromesso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo del progetto: il progetto che contiene la funzione dell'account di servizio compromesso.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
   1. Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   2. Nel file JSON, tieni presente i seguenti campi.
   • projectId: il progetto che contiene la risorsa potenzialmente compromessa l'account di servizio.
   • callerUserAgent: lo user agent anomalo.
   • anomalousSoftwareClassification: il tipo di software.
   • notSeenInLast: il periodo di tempo utilizzato per stabilire una base di riferimento per la normalità comportamento degli utenti.

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

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

   Vai a IAM

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

3. Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencata nella riga Email entità nella scheda Riepilogo dei dettagli dei risultati e controllare i ruoli concessi.

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

   Vai ad Account di servizio

5. Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencata nella riga Email entità nella scheda Riepilogo dei dettagli del risultato.

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

Passaggio 3: controlla i log

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

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

Privilege Escalation: Changes to sensitive Kubernetes RBAC objects

Per eseguire l’escalation del privilegio, un utente potenzialmente malintenzionato ha tentato di modificare un Accesso basato sui ruoli ClusterRole, RoleBinding o ClusterRoleBinding di controllo (RBAC) dell'oggetto cluster-admin sensibile 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli 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 la richiesta corpo del messaggio 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. 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Escalation dei privilegi
2. Conferma la sensibilità dell'oggetto sottoposto a query e se la modifica è giustificata.
3. Per le associazioni, puoi controllare l'oggetto e verificare se 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 per verificare se l'azione sia 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 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 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 MITRE ATT&CK.
     • Risultati correlati: collega 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 il una richiesta di firma del certificato specifica.

3. 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Aumento dei privilegi.
2. Verifica se l'accesso a cluster-admin era garantito.

3. Se l'email dell'entità non è un account di servizio, contatta il proprietario per verificare se l'azione sia 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 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 cluster-admin ruolo.

Passaggio 1: esamina i dettagli dei risultati

1. Apri Privilege Escalation: Creation of sensitive Kubernetes bindings 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.
     • Associazioni Kubernetes: i nodi Kubernetes sensibili associazione o ClusterRoleBinding 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 MITRE ATT&CK.
     • Risultati correlati: collega 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. 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Aumento 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 per verificare se l'azione sia 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à.

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

Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials

Per eseguire l'escalation del privilegio, un utente potenzialmente malintenzionato ha eseguito una query per ottenere un certificato di firma del cliente (CSR), con il comando kubectl, utilizzando le credenziali di bootstrap compromesse.

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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri Privilege Escalation: Get Kubernetes CSR with compromised bootstrap credentials 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.
   • 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

Passaggio 2: controlla i log

Se il nome del metodo, che hai annotato nel campo Nome metodo nel risultato , è un metodo GET, segui questi passaggi:

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 il una 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 il CSR specifico è disponibile nel voce di log, analizza la sensibilità della voce 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 la sezione SecurityContext v1 core nella documentazione di Kubernetes.

Passaggio 1: esamina i dettagli dei risultati

1. Apri Privilege Escalation: Launch of privileged Kubernetes container 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.
     • 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

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

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

Passaggio 2: controlla i log

1. Nella scheda Riepilogo dei dettagli del risultato in Nella console Google Cloud, vai a Esplora log facendo clic sul link nella URI 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 nell'attributo Campo Nome visualizzato della risorsa nei dettagli del risultato.

   • 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 risultato: Aumento 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 segnali di attività dannosa da parte del nei log.

4. Se l'email dell'entità non è un servizio contatta il proprietario dell'account per verificare se si tratta di un'entità legittima l'azione non è stata eseguita dal 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 viene considerata inattiva se è rimasta inattiva per più di 180 giorni.

Per rispondere a questo risultato, procedi nel seguente modo:

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 dei risultati, nella scheda Riepilogo, prendi nota dei valori di campi seguenti.

   Nella sezione Che cosa è stato rilevato:

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

   In Risorsa interessata:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

1. 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 risultato, nella sezione Link correlati Fai clic sul link URI Cloud Logging per aprire Esplora log.

Passaggio 4: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Rimuovi l'accesso del proprietario dell'email entità se viene compromessa.
• Rimuovi il ruolo IAM sensibile appena assegnato dall'account di servizio inattivo.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 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 dall'assistenza clienti Google Cloud.
• Per limitare gli utenti che possono creare account di servizio, utilizza il Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizza 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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Impersonation of Service Account for Admin Activity, come indicato in 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:
     • Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud.
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega 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, in particolare i seguenti campi:
     • Nome completo risorsa: il nome del cluster.
   • Link correlati, in particolare i seguenti campi:
     • URI Cloud Logging: link alle voci di Logging.
     • Metodo MITRE ATT&CK: link alla documentazione MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 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 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

Il parametro Anomalous Multistep Service Account Delegation viene rilevato esaminando Audit log delle attività di amministrazione per verificare 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 dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud.
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione.
     • Nome metodo: il metodo chiamato.
     • Informazioni relative alla delega 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 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 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 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 dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Multistep Service Account Delegation for Data Access, 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:
     • Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla delega 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 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 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 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 dei risultati

1. Apri il risultato Privilege Escalation: Anomalous Service Account Impersonator for Admin Activity, 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:

     • Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud
     • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
     • Nome metodo: il metodo chiamato
     • Informazioni relative alla delega 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.

Passaggio 2: ricerca i metodi di attacco e di risposta

1. Contatta il proprietario dell'account di servizio nel campo Email entità. Verifica se l'azione è stata eseguita dal legittimo proprietario.
2. Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 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 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 furto d'identità anomalo dell'account di servizio viene rilevato esaminando l'accesso ai dati Audit log per vedere se si è verificata un'anomalia nella rappresentazione di un account di servizio richiesta.

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 dei risultati, nella scheda Riepilogo, prendi nota dei valori seguenti campi.

   Nella sezione Che cosa è stato rilevato:

   • Email entità: l'account di servizio finale nel furto d'identità utilizzata per accedere a Google Cloud
   • Nome servizio: il nome dell'API del servizio Google Cloud coinvolto nella richiesta di rappresentazione
   • Nome metodo: il metodo chiamato
   • Informazioni relative alla delega 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. Analizzare le entità della catena di delega per verificare se le è anomala e se uno o più account sono stati compromessi.
3. Contatta il proprietario del chiamante che ha usato l'impersonificazione nell'account di servizio informazioni sulle deleghe. Conferma se il legittimo proprietario ha condotto un'azione.

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta la possibilità di eliminare l'account di servizio potenzialmente compromesso, quindi 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 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 Servizio Criteri dell'organizzazione.
• Per identificare e correggere i ruoli eccessivamente permissivi, utilizzare il motore per suggerimenti IAM.

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 le credenziali dell'account di servizio potrebbero essere compromesse e l'azione immediata deve essere preso.

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. Gravità è HIGH se la chiamata API che ha attivato questo risultato è non autorizzato: l'account di servizio non dispone dell'autorizzazione per interroga le proprie autorizzazioni IAM con API projects.getIamPolicy.
     • Email principale: l'account di servizio potenzialmente compromesso.
     • IP chiamante: indirizzo IP interno o esterno
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa:
     • Nome completo del progetto: il progetto che contiene 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 MITRE ATT&CK.
     • Risultati correlati: collega a eventuali risultati correlati.
   1. Per visualizzare il file JSON completo per il risultato, fai clic sulla scheda JSON.

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

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

   Vai a IAM

2. Se necessario, seleziona il progetto elencato nel campo projectID della alla ricerca di JSON.

3. Nella pagina visualizzata, inserisci il nome dell'account nella casella Filtro nella pagina visualizzata. elencate in 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 risultato: Scoperta dei gruppi di autorizzazioni: gruppi 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 risultati.

• 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. Dopo l'eliminazione di un host, non è possibile eseguire il backup delle applicazioni associate all'host.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. Attenzione valutare le informazioni raccolte nell'indagine per determinare il modo migliore per risolvere i risultati.

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

Inhibit System Recovery: Google Cloud Backup and DR remove plan

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

Il seguente piano di risposta potrebbe essere appropriato per questo risultato. 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 sezione e la 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 nuovamente un modello, vai alla scheda Piani di backup e seleziona Modelli, quindi seleziona l'opzione Crea modello.

Inhibit System Recovery: Google Cloud Backup and DR delete policy

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

Inhibit System Recovery: Google Cloud Backup and DR delete profile

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

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

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

Data Destruction: Google Cloud Backup and DR expire image

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

Data Destruction: Google Cloud Backup and DR expire all images

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

Data Destruction: Google Cloud Backup and DR remove appliance

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

Passaggio 1: esamina i dettagli dei risultati

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

Impact: Google Cloud Backup and DR reduced backup expiration

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

Per rispondere a questo risultato, procedi nel seguente modo:

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. 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 è stato ha eseguito un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui scade il backup è stato ridotto.
   • 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 Impact: Google Cloud Backup and DR reduced backup frequency di ricerca, come descritto in Analisi dei 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 è stato ha eseguito un'azione
   • Risorsa interessata
     • Nome visualizzato della risorsa: il progetto in cui viene generata la frequenza di backup è stato ridotto.
   • 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.

Lateral Movement: Modified Boot Disk Attached to Instance

Gli audit log vengono esaminati per rilevare movimenti sospetti di dischi tra le risorse delle istanze Compute Engine. Un disco di avvio potenzialmente modificato è stato collegato al tuo Compute Engine.

Passaggio 1: esamina i dettagli dei risultati

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

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

   Nella sezione Che cosa è stato rilevato:

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Passaggio 3: implementa la risposta

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

• Contatta il proprietario del progetto in cui è stata intrapresa l'azione.
• Valuta l'uso Avvio protetto per il tuo di istanze VM di 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 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 e collaborare con i proprietari delle applicazioni 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.

Privilege Escalation: AlloyDB Over-Privileged Grant

Rileva quando tutti i privilegi su un database AlloyDB per 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 dei risultati

1. Apri Privilege Escalation: AlloyDB Over-Privileged Grant come indicato in Revisione dei risultati.

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato database: il nome del database 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 overbroad.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa di 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 MITRE ATT&CK.

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

Passaggio 2: rivedi i privilegi del database

1. Connettiti all'istanza AlloyDB per PostgreSQL.
2. 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. Usa il metacomando \df e controllare quali privilegi sono assegnati per funzioni o procedure database elencato in Nome visualizzato del database (da 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 PostgreSQL pgaudit, che registrano query eseguite sul database, utilizzando i seguenti filtri:
   • protoPayload.request.database="var class="edit">database"

Passaggio 4: ricerca i metodi di attacco e di risposta

1. Esamina la voce del framework MITRE ATT&CK per questo tipo di risultato: esfiltrazione da servizi 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 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) nelle tabelle utente. Il super user (un ruolo con accesso molto ampio) in genere non deve essere utilizzato per scrivere nelle tabelle degli utenti. Un account utente con accesso più limitato. 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 risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

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

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

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Nome visualizzato database: il nome del database nella Istanza AlloyDB per PostgreSQL interessata.
     • Nome utente database: il super user.
     • Query sul database: la query SQL eseguita durante la scrittura nelle tabelle utente.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome della risorsa di 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 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 su il link in cloudLoggingQueryURI (dal Passaggio 1). La pagina Esplora log include tutti i log relativi ai AlloyDB per PostgreSQL.
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 super user.
• Potresti creare un nuovo utente con accesso limitato per i diversi tipi di query usati sull'istanza.
  • Concedi al nuovo utente solo le autorizzazioni necessarie per eseguire le sue query.
  • Aggiorna le credenziali per i client che si connettono all'istanza AlloyDB per PostgreSQL

Rilevamenti dei metadati amministrativi di Compute Engine

Persistence: GCE Admin Added SSH Key

Descrizione	Azioni
La chiave dei metadati dell'istanza Compute Engine ssh-keys è stata modificata su un'istanza stabilita.	La chiave dei metadati dell'istanza Compute Engine ssh-keys è stata modificata in un'istanza creata più di sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se implementate da un avversario per introdurre un nuovo accesso alla vostra 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 oppure startup-script-url è stato modificato su un'istanza creata più di sette giorni fa. Verifica se la modifica è stata apportata intenzionalmente da un membro o se è stata implementate da un avversario per introdurre un nuovo accesso alla vostra 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/

Rilevamenti 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 Security Command Center. La tabella seguente contiene Google Workspace le minacce, i MITRE ATT&CK pertinenti, framework e i dettagli sul eventi che attivano i risultati. Puoi anche controllare i log usando filtri specifici, e combinare tutte le informazioni per rispondere a Google Workspace. minacce.

Initial Access: Disabled Password Leak

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

Descrizione	Azioni
L'account di un membro è stato disattivato a causa di una fuga di password rilevato.	Reimposta le password degli account interessati e consiglia ai membri di Utilizzare password efficaci e univoche per gli account aziendali.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="login.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Fdata_access Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRO: 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 un accesso sospetto all'account di un membro e bloccato.	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 dell'evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/login#suspicious_login

Initial Access: Account Disabled Hijacked

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

Descrizione	Azioni
L'account di un membro è stato sospeso a causa di attività sospetta.	Questo account è stato compromesso. Reimpostare la password dell'account e incoraggiare 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: MITRO: https://attack.mitre.org/techniques/T1078/ Dettagli dell'evento 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 che lo fornisca prontamente.	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.
		Eventi di ricerca che attivano questo risultato: 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: i domainName elencati in risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Eventi di ricerca che attivano questo risultato: MITRO: https://attack.mitre.org/techniques/T1098/ Dettagli dell'evento Workspace: https://developers.google.com/admin-sdk/reports/v1/appendix/activity/admin-domain-settings#TOGGLE_SSO_ENABLED

Persistence: SSO Settings Changed

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

Descrizione	Azioni
Le impostazioni SSO dell'account amministratore sono state modificate.	Le impostazioni SSO per la tua organizzazione sono state modificate. Verifica se la modifica è stata apportata intenzionalmente da un membro o se 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: i domainName elencati in risultato ORGANIZATION_ID: l'ID della tua organizzazione
		Eventi di ricerca che attivano questo risultato: MITRO: 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 il tuo dell'organizzazione. Scopri se si è trattato di una modifica intenzionale delle norme da parte di un amministratore o se si tratta di un tentativo da parte di un avversario di creare i compromissioni più facilmente.	Controlla i log utilizzando i seguenti filtri: protopayload.resource.labels.service="admin.googleapis.com" logName="organizations/ORGANIZATION_ID/logs/cloudaudit.googleapis.com%2Factivity Sostituisci ORGANIZATION_ID con l'ID della tua organizzazione.
		Eventi di ricerca che attivano questo risultato: MITRO: https://attack.mitre.org/techniques/T1562/ Dettagli dell'evento 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 di Google Workspace sono disponibili solo a livello di organizzazione attivazioni di Security Command Center. I log di Google Workspace non possono essere analizzate per rilevare attivazioni a livello di progetto.

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

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

Gli strumenti includono avvisi, una dashboard per la sicurezza, consigli per la sicurezza e può aiutarti a indagare e a risolvere le minacce.

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

• Se hai ancora accesso al tuo account, modifica o reimposta il tuo password e attiva Verifica in due passaggi.
• Contatta il tuo Google Workspace amministratore o al team del tuo che gestisce il tuo account Google Workspace. Utilizza questi risultati a indicare che un account potrebbe essere stato compromesso.

Rilevamenti delle minacce di Cloud IDS

Cloud IDS: THREAT_ID

I risultati di Cloud IDS sono generati da Cloud IDS, un servizio di sicurezza che monitora il traffico da e verso Risorse Google Cloud per le minacce. Quando Cloud IDS rileva un una minaccia, invia informazioni relative alla minaccia, come l'indirizzo IP di origine, indirizzo e numero di porta di destinazione a Event Threat Detection, che quindi invia alla ricerca di una minaccia.

Passaggio 1: esamina i dettagli dei risultati

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

2. Nei dettagli dei risultati, nella scheda Riepilogo, esamina i valori elencati in le seguenti sezioni:

   • Che cosa è stato rilevato, in particolare i seguenti campi:
     • Protocollo: il protocollo di rete utilizzato
     • Ora evento: quando si è verificato l'evento.
     • Descrizione: ulteriori informazioni sul risultato
     • Gravità: la gravità dell'avviso.
     • IP di destinazione: l'IP di destinazione del traffico di rete.
     • Porta di destinazione: la porta di destinazione del traffico di rete.
     • IP di origine: l'IP di origine del traffico di rete.
     • Porta di origine: la porta di origine del traffico di rete.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo 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
   • Servizio di rilevamento
     • Finding Category (Trova categoria) Il nome della minaccia Cloud IDS

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

Passaggio 2: ricerca i metodi di attacco e di risposta

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

Puoi trovare ulteriori informazioni sull'evento rilevato nel log originale facendo clic sul link nel campo URI Cloud Logging nel risultato i dettagli.

Risposte di Container Threat Detection

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

Added Binary Executed

Un file binario che non faceva parte dell'immagine container originale era eseguito. Gli aggressori di solito installano strumenti di sfruttamento e malware 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 risultato, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Added 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 aggiunto.
     • Argomenti: gli argomenti forniti durante la chiamata al programma 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 nel 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 Pod eseguito.

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

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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à elencata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il programma binario aggiunto eseguendo:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente dei container eseguendo:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

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

Passaggio 7: implementa la risposta

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

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

Added Library Loaded

È stata caricata una libreria che non faceva parte dell'immagine container originale. Gli aggressori potrebbero caricare librerie dannose nei programmi esistenti per bypassare le protezioni di esecuzione del codice e nascondere il codice dannoso. Garantire che i container siano immutabili è 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 noto indicatore di compromissione (IoC). Per rispondere ricerca, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Added 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 programma 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 nel 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 container. Risultati correlati potrebbero indicare che questa attività era dannosa, anziché l'inosservanza delle best practice.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato in resource.name. Prendi nota di 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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 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 dei container eseguendo:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Trasferimento di strumenti in entrata, Moduli condivisi.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

Passaggio 7: implementa la risposta

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

• Se la libreria doveva essere inclusa nel container, ricrea l'immagine container includendo la libreria. In questo modo, il container 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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Execution: Added 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 aggiunto.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario aggiunto.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo 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 di VirusTotal: link alla pagina di analisi di VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui Pod eseguito.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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à elencata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso aggiunto:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

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

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

Execution: Added Malicious Library Loaded

È stata caricata una libreria dannosa che non faceva parte dell’immagine container originale. Gli aggressori potrebbero caricare librerie dannose nei programmi esistenti per bypassare 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 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 programma binario del processo che ha caricato libreria.
     • Librerie: dettagli sulla libreria aggiunta.
     • Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa nel cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui Pod eseguito.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 seguenti comandi.

   Per i cluster di zona:

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

   Per i cluster a livello di regione:

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

5. Recupera la libreria dannosa aggiunta:

     kubectl cp Pod_Namespace/Pod_Name: Added_Library_Fullpath -c Container_Name  local_file
   

   Sostituisci local_file con un percorso locale per archiviare il malware aggiunto 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 il MITRE ricerca.
3. Controlla il valore hash SHA-256 della libreria segnalata 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 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 risultati.

• 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 programma binario eseguito con questo codice:

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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Execution: Built in 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 integrato.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario integrato.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo 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 di VirusTotal: link alla pagina di analisi di VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui Pod eseguito.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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à elencata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso integrato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

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

• 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 programma binario eseguito con questo codice:

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

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

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato 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.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo 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 di VirusTotal: link alla pagina di analisi di VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui Pod eseguito.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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à elencata in resource.labels.location
   • project_name: il nome del progetto elencato in resource.project_display_name

5. Recupera il file binario dannoso modificato:

     kubectl cp Pod_Namespace/Pod_Name:Process_Binary_Fullpath -c Container_Name  local_file
   

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

6. Connettiti all'ambiente dei container:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

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

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

Execution: Modified Malicious Library Loaded

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

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

Gli aggressori potrebbero caricare librerie dannose nei programmi esistenti per bypassare 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 risultato di Execution: Modified 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 programma binario del processo che ha caricato libreria.
     • Librerie: dettagli sulla libreria modificata.
     • Argomenti: gli argomenti forniti durante la chiamata al processo. binario.
     • Container: il nome del contenitore interessato.
     • URI container: il nome dell'immagine container di cui si esegue il deployment.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo risorsa: il nome completo della risorsa nel cluster.
   • Link correlati, in particolare i seguenti campi:
     • Indicatore di VirusTotal: link alla pagina di analisi di VirusTotal.

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

   • sourceProperties:
     • VM_Instance_Name: il nome del nodo GKE in cui Pod eseguito.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato in resource.name. Prendi nota di 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 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 risorsa nella Scheda Riepilogo dei dettagli del risultato e dello spazio dei nomi del pod elencato in Pod_Namespace, se necessario.

4. Seleziona il pod elencato in Pod_Name. Prendi nota di tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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 il MITRE ricerca.
3. Controlla il valore hash SHA-256 della libreria segnalata 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 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 risultati.

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

Malicious Script Executed

Un modello di machine learning ha identificato il codice bash eseguito come dannoso. Gli aggressori possono usare bash per trasferire strumenti ed eseguire comandi senza programmi binari. Garantire che i container siano immutabili è una best practice importante. L’uso degli script per gli strumenti di trasferimento può imitare la tecnica dell’aggressore trasferimento dello strumento in entrata e causare rilevamenti indesiderati.

Per rispondere a questo risultato, procedi nel seguente modo:

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Malicious Script 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: 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 di script, ad esempio bash -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 file JSON, tieni presente i 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 Pod eseguito.

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

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato nella riga Nome completo risorsa nella Scheda Riepilogo dei dettagli del 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 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 tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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 dei container eseguendo questo comando:

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

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento di strumenti in entrata.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

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

Malicious URL Observed

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

Per rispondere a questo risultato, segui questi passaggi.

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Malicious URL Observed 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:
     • URI: l'URI dannoso osservato.
     • File binario aggiunto: il percorso completo del file binario del processo che ha ricevuto gli argomenti che contengono l'URL dannoso.
     • Argomenti: gli argomenti forniti durante la chiamata al programma 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, prendi nota del 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 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. La sezione Cluster si apre una pagina.

4. Nella sezione Metadati della **pagina dei dettagli del cluster, annota eventuali delle informazioni definite dall'utente che potrebbero essere utili per risolvere ad esempio le informazioni che identificano il proprietario del cluster.

5. Fai clic sulla scheda Nodi.

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

7. Nella scheda Dettagli della pagina Dettagli nodo, Annotazioni, nota il valore del parametro 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 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 di 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. I Dettagli pod si apre una pagina.

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 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 dei container eseguendo questo comando:

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

   Sostituisci CONTAINER_NAME con il nome del container che hai notato nel riepilogo dei risultati in precedenza.

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Controllare lo stato dei siti segnalato dalla funzione Navigazione sicura per informazioni 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 ricerca MITRE.

Passaggio 7: implementa la risposta

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

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

Reverse Shell

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

Passaggio 1: esamina i dettagli dei risultati

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 nel cluster.
     • Nome completo del progetto:
   • Nella visualizzazione dettagliata del risultato, fai clic sulla scheda JSON.
   • Nel file JSON, tieni presente i seguenti campi.
   • resource:
     • project_display_name: il nome del progetto che contiene 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 Pod eseguito.
     • 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 del connessione
     • Reverse_Shell_Stdin_Redirection_Src_Port: la porta locale
     • Container_Image_Uri: il nome dell'immagine container che viene eseguita.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato in resource.name. Prendi nota di tutti i metadati 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 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 tutti i metadati relativi al pod il 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 visualizzata, procedi nel seguente modo:

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

Passaggio 5: esamina il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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. Avvia una shell nell'ambiente del container eseguendo:

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

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

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

     ps axjf
   

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script, Trasferimento di strumenti in entrata.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

Passaggio 7: implementa la risposta

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

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

Unexpected Child Shell

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

Per rispondere a questo risultato, segui questi passaggi.

Passaggio 1: esamina i dettagli dei risultati

1. Apri un risultato di Unexpected Child Shell 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:
     • Processo padre: il processo che ha creato inaspettatamente il processo della shell secondaria.
     • Processo figlio: il processo shell figlio.
     • Argomenti: gli argomenti forniti al file binario del processo della shell secondaria.
     • Variabili di ambiente: le variabili di ambiente del file binario dei processi della shell figlio.
     • Container: il nome del container.
     • 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 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. Fai clic sulla scheda JSON e prendi nota dei seguenti campi:

+processes: un array contenente tutti i processi correlati al risultato. Questo array include il processo shell figlio e il processo padre. +resource: +project_display_name: il nome del progetto che contiene gli asset. +sourceProperties: +VM_Instance_Name: il nome del nodo GKE in cui Pod eseguito.

Passaggio 2: esamina il cluster e il nodo

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

   Vai ai cluster Kubernetes

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

3. Seleziona il cluster elencato in resource.name. Prendi nota di 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 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 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 di 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. I Dettagli pod si apre una pagina.

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

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

Passaggio 5: analizza il container in esecuzione

Se il container è ancora in esecuzione, potrebbe essere possibile esaminare 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 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 questo comando:

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

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

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

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

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

     ps axjf
   

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

Passaggio 6: ricerca i metodi di attacco e di risposta

1. Esamina le voci del framework MITRE ATT&CK per questo tipo di risultato: Interprete di comandi e script: Unix Shell.
2. Per sviluppare un piano di risposta, combina i risultati della tua indagine con il MITRE ricerca.

Passaggio 7: implementa la risposta

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

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

Risposta di VM Threat Detection

Per saperne di più su VM Threat Detection, consulta Panoramica di VM Threat Detection.

Execution: Cryptocurrency Mining Hash Match

VM Threat Detection ha rilevato attività di mining di criptovaluta mediante la corrispondenza della memoria hash di programmi in esecuzione rispetto ad hash di memoria di mining di criptovaluta noti software.

Per rispondere a questi risultati, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

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.
     • File binario del programma: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
     • Nomi processi: il nome del processo in esecuzione nell'istanza VM associato alle corrispondenze della firma rilevate.

     VM Threat Detection può riconoscere le build del kernel 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 VM Threat Detection non riesce riconoscere il kernel, ad esempio se è personalizzato creato: il campo processes del risultato non è compilato.

   • Risorsa interessata, in particolare i seguenti campi:

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

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

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

Passaggio 2: controlla i log

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

   Vai a Esplora log

2. Nella barra degli strumenti della console Google Cloud, seleziona il progetto che 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 alla riga Nome completo risorsa nella scheda Riepilogo della trovare i dettagli.

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: 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 un sistema di rilevamento degli endpoint e di risposta alle domande.

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. Considera 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 di il nome binario nel pattern di ricerca, in questo caso xmrig. Esamina la risultati di ricerca.

   • Esamina i processi in esecuzione, soprattutto quelli con un elevato utilizzo della CPU, per vedere se ce n'è qualcuno che non riconosci. Determina se applicazioni associate sono applicazioni 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, vedi Nomi software e regole YARA e la relativa documentazione per 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 file 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 YARA Rule

VM Threat Detection ha rilevato attività di mining di criptovaluta mediante la corrispondenza della memoria 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 dei risultati

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

     • Nome regola YARA: la regola attivata per i rilevatori YARA.
     • File binario del programma: il percorso assoluto del processo.
     • Argomenti: gli argomenti forniti durante la chiamata al programma binario del processo.
     • Nomi processi: il nome dei processi in esecuzione nella VM all'istanza associata alle corrispondenze di 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 VM Threat Detection non riesce riconoscere il kernel, ad esempio se è personalizzato creato: il campo processes del risultato non è compilato.

   • Risorsa interessata, in particolare i seguenti campi:

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

   • Link correlati, in particolare i seguenti campi:

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

3. Per 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 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. Rivedi istanza i dettagli, incluse le impostazioni di rete e 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 un sistema di rilevamento degli endpoint e di risposta alle domande.

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, soprattutto quelli con un elevato utilizzo della CPU, per vedere se ce n'è qualcuno che non riconosci. Determina se applicazioni associate sono applicazioni 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, vedi Nomi software e regole YARA e la relativa documentazione per 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 file 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

VM Threat Detection ha rilevato più categorie di risultati all'interno di un singolo giorno da un'unica fonte. Una singola applicazione può attivare contemporaneamente Execution: Cryptocurrency Mining YARA Rule e Execution: Cryptocurrency Mining Hash Match findings.

Per rispondere a un risultato combinato, segui le istruzioni di risposta per 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, segui questi passaggi:

Passaggio 1: esamina i dettagli dei risultati

1. Apri il risultato Malware: Malicious file on disk (YARA), come indicato in Esamina 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 regola YARA: la regola YARA corrispondente.
     • File: l'UUID della partizione e il percorso relativo dell'elemento è stato rilevato il file dannoso.
   • Risorsa interessata, in particolare i seguenti campi:
     • Nome completo della risorsa: il nome completo della risorsa interessata Istanza VM, incluso l'ID del progetto che la contiene.

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

4. Nel file JSON, tieni presente i 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. Rivedi istanza i dettagli, incluse le impostazioni di rete e accesso.

Passaggio 4: ricerca i metodi di attacco e di 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 potenzialmente dannosi, URL, domini e indirizzi IP.

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 la rimozione, utilizzare una soluzione di rilevamento e risposta agli endpoint.

3. Se necessario, interrompi l'account compromesso un'istanza e sostituirla con nuova istanza.

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

Correggi le vulnerabilità correlate

Per evitare che le minacce si ripetano, esamina e correggi le vulnerabilità correlate o 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. Rivedi il risultato della minaccia e copia il valore di un attributo che figura nell'ambito di eventuali vulnerabilità o configurazioni errate correlate risultato, ad esempio l'indirizzo email principale o il nome della persona interessata risorsa.

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 che contiene l'attributo che hai notato nella minaccia ricerca.

   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. Tra gli attributi visualizzati, seleziona il tipo di attributo che indicati nel risultato 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 da alla scoperta della minaccia. L'elenco di valori visualizzato viene aggiornato 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 mostrano molti risultati, filtrali per selezionando altri filtri dal riquadro Filtri rapidi.

   Ad esempio, per mostrare solo Vulnerability e Misconfiguration risultati della classe contenenti i valori degli attributi selezionati, Scorri verso il basso fino alla sezione Ricerca del corso in 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.

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

Le configurazioni errate e le violazioni della conformità identificano i punti deboli nelle risorse che potrebbe essere sfruttata. In genere, gli errori di configurazione sono correzioni implementate, 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. Una correzione potrebbe non essere efficace per la protezione delle risorse perché i metodi esatti utilizzati per ottenere l'exploit potrebbero non essere noti.

Ad esempio, un risultato Added Binary Executed indica che un utente non autorizzato è stato avviato in un container. 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. Devi scoprire il modo in cui l'immagine container è stata danneggiata. l'exploit. Determinare se il file è stato aggiunto tramite una porta configurata in modo errato o in altro modo richiede un'indagine approfondita. Un analista con un esperto del tuo sistema potrebbe dover esaminare i suoi punti deboli.

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

L'ampiezza dei vettori di attacco rende difficile fornire passaggi per porvi rimedio che funzionano in tutte le situazioni. Il ruolo di Security Command Center nella sicurezza del cloud è identificare le risorse colpite quasi in tempo reale, dirti quali minacce affrontare e fornire prove e contesto a supporto delle indagini. Tuttavia, il personale addetto alla sicurezza deve utilizzare le informazioni esaustive in Security Command Center risultati per determinare i modi migliori per risolvere i problemi e mettere in sicurezza le risorse contro attacchi futuri.

Passaggi successivi

• Vedi la panoramica di Event Threat Detection per saperne di più sul servizio e sulle minacce che rileva.

• Vedi la panoramica di Container Threat Detection per scopri come funziona il servizio.

• Vedi la panoramica di VM Threat Detection per saperne di più sul servizio e sulle minacce che rileva.