Raccogli i log di Avaya Aura

Versione parser: 3.0

Supportata in:

Google SecOps SIEM

Questo documento spiega come importare i log di Avaya Aura in Google Security Operations utilizzando l'agente Bindplane.

Avaya Aura è una piattaforma di comunicazioni unificate che genera messaggi syslog per eventi di accesso/disconnessione degli utenti, modifiche alla configurazione del sistema ed eventi di sicurezza. Il parser estrae i campi dai messaggi syslog utilizzando i pattern grok e li mappa al modello UDM (Unified Data Model).

Prima di iniziare

Assicurati di soddisfare i seguenti prerequisiti:

• Un'istanza Google SecOps
• Windows Server 2016 o versioni successive oppure host Linux con systemd
• Connettività di rete tra l'agente Bindplane e il sistema Avaya Aura
• Se l'esecuzione avviene dietro un proxy, assicurati che le porte del firewall siano aperte in base ai requisiti dell'agente Bindplane
• Accesso privilegiato ad Avaya Aura

Ottieni le credenziali di Google SecOps per l'agente Bindplane

Per autenticare l'agente Bindplane in Google SecOps, scegli uno dei seguenti metodi:

• Nuovi deployment: utilizza l'API Chronicle (opzione 1).
• Deployment legacy: continua a utilizzare il file di autenticazione dell'acquisizione (opzione 2) fino alla dismissione dell'API Ingestion il 20 luglio 2027.

Opzione 1: crea un account di servizio per l'API Chronicle (consigliato)

1. Accedi alla consoleGoogle Cloud e seleziona il progetto Google Cloud collegato alla tua istanza di Google SecOps.
2. Vai a IAM e amministrazione > Service account.
3. Fai clic su Crea account di servizio.
4. Fornisci i seguenti dettagli di configurazione:
   • Nome account di servizio: inserisci un nome per l'account (ad esempio bindplane-ingest).
   • Descrizione service account: inserisci una descrizione (ad esempio, Bindplane agent log ingestion).
5. Fai clic su Crea e continua.
6. Nella sezione Concedi a questo account di servizio l'accesso al progetto, fai clic su Seleziona un ruolo e seleziona Chronicle Editor.
7. Fai clic su Continua e poi su Fine.
8. Fai clic sul account di servizio che hai creato, quindi vai alla scheda Chiavi.
9. Fai clic su Aggiungi chiave > Crea nuova chiave.
10. Seleziona JSON e fai clic su Crea. Il file della chiave viene scaricato sul computer.
11. Salva il file della chiave come ingestion-auth.json nella directory del raccoglitore Bindplane (/opt/observiq-otel-collector/ingestion-auth.json su Linux o C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json su Windows) o aggiorna creds_file_path in config.yaml in modo che corrisponda al percorso in cui lo salvi.
12. Vai a IAM e amministrazione > Impostazioni e copia il Numero progetto. Ti servirà per la configurazione dell'esportatore.

Nota: la chiave JSON è una credenziale. Limita l'accesso al file sull'host Bindplane e ruota la chiave in base alle policy della tua organizzazione.

Opzione 2: scarica il file di autenticazione dell'acquisizione (legacy)

1. Accedi alla console Google SecOps.
2. Vai a Impostazioni > Gestione dei dati > Agenti di raccolta. Se utilizzi una piattaforma solo SIEM, vai a Impostazioni > Agenti di raccolta.
3. Scarica il file di autenticazione dell'acquisizione.
4. Salva il file in modo sicuro sul sistema in cui verrà installato l'agente Bindplane.

Nota: questo file autentica l'agente nell'API Ingestion precedente (malachiteingestion-pa.googleapis.com), che Google ha programmato per la fine del ciclo di vita il 20 luglio 2027. Pianifica il passaggio all'Opzione 1 prima di questa data.

Ottieni l'ID cliente Google SecOps

1. Accedi alla console Google SecOps.
2. Vai a Impostazioni > Amministrazione > Profilo. Se utilizzi una piattaforma solo SIEM, vai a Impostazioni > Profilo.

3. Copia e salva l'ID cliente dalla sezione Dettagli organizzazione.

   Nota: l'ID cliente è obbligatorio per configurare l'esportatore dell'agente Bindplane.

Installa l'agente Bindplane

Installa l'agente Bindplane sul tuo sistema operativo Windows o Linux seguendo le istruzioni riportate di seguito.

Installazione di finestre

1. Apri il prompt dei comandi o PowerShell come amministratore.

2. Esegui questo comando:

   msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
   

3. Attendi il completamento dell'installazione.

4. Verifica l'installazione eseguendo:

   sc query observiq-otel-collector
   

   Il servizio dovrebbe essere visualizzato come RUNNING.

Installazione di Linux

1. Apri un terminale con privilegi root o sudo.

2. Esegui questo comando:

   sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
   

3. Attendi il completamento dell'installazione.

4. Verifica l'installazione eseguendo:

   sudo systemctl status observiq-otel-collector
   

   Il servizio dovrebbe essere visualizzato come attivo (in esecuzione).

Risorse aggiuntive per l'installazione

Per ulteriori opzioni di installazione e risoluzione dei problemi, consulta la guida all'installazione dell'agente Bindplane.

Nota: la configurazione dell'esportatore dell'API Chronicle richiede Bindplane Collector v1.106.0 o versioni successive. I comandi precedenti installano l'ultima release. Se stai aggiornando un'installazione esistente, esegui l'upgrade del raccoglitore prima di modificare la configurazione.

Configura l'agente Bindplane per importare il syslog e inviarlo a Google SecOps

Individua il file di configurazione

• Linux:

  sudo nano /opt/observiq-otel-collector/config.yaml
  

• Windows:

  notepad "C:\Program Files\observIQ OpenTelemetry Collector\config.yaml"
  

Modifica il file di configurazione

• Sostituisci l'intero contenuto di config.yaml con la seguente configurazione:

  receivers:
    udplog:
      listen_address: "0.0.0.0:514"
  
  exporters:
    chronicle/avaya_aura:
      protocol: https
      # Region of your instance, for example us, europe, asia-southeast1
      location: <LOCATION>
      # Project number of the Google Cloud project linked to the instance
      project: '<PROJECT_NUMBER>'
      compression: gzip
      creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json'
      customer_id: '<customer_id>'
      endpoint: chronicle.googleapis.com
      log_type: AVAYA_AURA
      raw_log_field: body
  
  service:
    pipelines:
      logs/avaya_aura_to_chronicle:
        receivers:
          - udplog
        exporters:
          - chronicle/avaya_aura
  

Parametri di configurazione

Sostituisci i seguenti segnaposto:

• Configurazione del ricevitore:

  • listen_address: indirizzo IP e porta su cui ascoltare:
    • 0.0.0.0 per ascoltare su tutte le interfacce (consigliato)
    • La porta 514 è la porta syslog standard (richiede l'accesso root su Linux; utilizza 1514 per l'accesso non root)

• Configurazione dell'esportatore:

  • creds_file_path: percorso completo del file della chiave JSON del account di servizio (opzione 1):
    • Linux: /opt/observiq-otel-collector/ingestion-auth.json
    • Windows: C:\Program Files\observIQ OpenTelemetry Collector\ingestion-auth.json
  • customer_id: ID cliente copiato dalla console Google SecOps
  • location: sostituisci <LOCATION> con la regione della tua istanza Google SecOps (ad esempio us, europe o asia-southeast1). L'esportatore aggiunge chronicle.googleapis.com come prefisso a questo valore. Per l'elenco completo, consulta Endpoint regionali.
  • project: sostituisci <PROJECT_NUMBER> con il numero di progetto da IAM e amministrazione > Impostazioni.
  • endpoint: mantieni l'impostazione chronicle.googleapis.com.

Esportatore API di importazione precedente

• Se utilizzi il file di autenticazione dell'acquisizione dell'Opzione 2, sostituisci il blocco exporters con il seguente. Imposta creds_file_path sul percorso del file di autenticazione dell'acquisizione e, se l'istanza si trova al di fuori degli Stati Uniti, sostituisci malachiteingestion-pa.googleapis.com con il tuo endpoint regionale (ad esempio, europe-malachiteingestion-pa.googleapis.com).

  exporters:
    chronicle/avaya_aura:
      compression: gzip
      creds_file_path: '/opt/observiq-otel-collector/ingestion-auth.json'
      customer_id: '<customer_id>'
      endpoint: malachiteingestion-pa.googleapis.com
      log_type: AVAYA_AURA
      raw_log_field: body
  

Nota: questo strumento di esportazione smetterà di funzionare quando l'API Ingestion non sarà più disponibile il 20 luglio 2027.

Salva il file di configurazione

• Dopo la modifica, salva il file:
  • Linux: premi Ctrl+O, poi Enter e infine Ctrl+X
  • Windows: fai clic su File > Salva.

Riavvia l'agente Bindplane per applicare le modifiche

• Per riavviare l'agente Bindplane in Linux, esegui questo comando:

  sudo systemctl restart observiq-otel-collector
  

  1. Verifica che il servizio sia in esecuzione:

     sudo systemctl status observiq-otel-collector
     

  2. Controlla i log per verificare la presenza di errori:

     sudo journalctl -u observiq-otel-collector -f
     

• Per riavviare l'agente Bindplane in Windows, scegli una delle seguenti opzioni:

  • Prompt dei comandi o PowerShell come amministratore:

    net stop observiq-otel-collector && net start observiq-otel-collector
    

  • Console Servizi:

    1. Premi Win+R, digita services.msc e premi Invio.
    2. Individua observIQ OpenTelemetry Collector.
    3. Fai clic con il tasto destro del mouse e seleziona Riavvia.

    4. Verifica che il servizio sia in esecuzione:

       sc query observiq-otel-collector
       

    5. Controlla i log per verificare la presenza di errori:

       type "C:\Program Files\observIQ OpenTelemetry Collector\log\collector.log"
       

Configura syslog in Avaya Aura

1. Accedi alla console Avaya Aura.
2. Vai a EM > System Configuration > Logging Settings > Syslog.
3. Attiva SYSLOG Delivery of Logs (Invio dei log SYSLOG).
4. Fai clic su Aggiungi.
5. Fornisci i seguenti dettagli di configurazione:
   • Indirizzo server: inserisci l'indirizzo IP dell'agente Bindplane.
   • Porta: inserisci la porta di ascolto dell'agente Bindplane.
6. Fai clic su Salva.
7. Fai clic su Conferma.
8. Riavvia Avaya Aura.

Tabella di mappatura UDM

Campo del log	mappatura UDM	Logica
data{}.@timestamp	metadata.event_timestamp	Il timestamp dell'evento viene analizzato dal campo di dati utilizzando il pattern grok e assegnato al campo event_timestamp nella sezione dei metadati dell'UDM.
data{}.host	principal.hostname	Il valore dell'host viene estratto dal campo di dati utilizzando il pattern grok e assegnato al campo hostname nella sezione principal di UDM.
data{}.portal	security_result.about.resource.attribute.labels.value	Il valore del portale viene estratto dal campo di dati utilizzando il pattern grok e assegnato come valore dell'etichetta Portal nella sezione about.resource.attribute.labels di security_result nell'UDM.
data{}.prod_log_id	metadata.product_log_id	Il valore prod_log_id viene estratto dal campo di dati utilizzando il pattern grok e assegnato al campo product_log_id nella sezione dei metadati dell'UDM.
data{}.sec_cat	security_result.category_details	Il valore sec_cat viene estratto dal campo di dati utilizzando il pattern grok e assegnato al campo category_details nella sezione security_result dell'UDM.
data{}.sec_desc	security_result.description	Il valore sec_desc viene estratto dal campo di dati utilizzando il pattern grok e assegnato al campo description nella sezione security_result di UDM.
data{}.severity	security_result.severity	Il valore della gravità viene estratto dal campo di dati utilizzando il pattern grok. Se la gravità è warn, fatal o error (senza distinzione tra maiuscole e minuscole), viene mappata a HIGH nel campo security_result.severity di UDM. In caso contrario, se la gravità è info (senza distinzione tra maiuscole e minuscole), viene mappata a LOW.
data{}.summary	security_result.summary	Il valore di riepilogo viene estratto dal campo di dati utilizzando il pattern grok e assegnato al campo di riepilogo nella sezione security_result di UDM.
data{}.user_id	target.user.userid	Il valore user_id viene estratto dal campo di dati utilizzando il pattern grok e assegnato al campo userid nella sezione target.user dell'UDM.
	extensions.auth.type	Il campo auth.type è impostato su AUTHTYPE_UNSPECIFIED se il campo event_name contiene log(in|on) o logoff (senza distinzione tra maiuscole e minuscole) o se il campo summary contiene login o logoff (senza distinzione tra maiuscole e minuscole) e il campo user_id non è vuoto.
	metadata.description	Il campo della descrizione viene compilato con il valore del campo desc, se non è vuoto.
	metadata.event_type	Il campo event_type viene determinato in base alla seguente logica: - Se il campo event_name contiene log(in|on) o il campo summary contiene login (senza distinzione tra maiuscole e minuscole) e il campo user_id non è vuoto, event_type viene impostato su USER_LOGIN. - Se il campo event_name contiene logoff o il campo summary contiene logoff (senza distinzione tra maiuscole e minuscole) e il campo user_id non è vuoto, event_type viene impostato su USER_LOGOUT. - Se il campo has_principal è true, event_type è impostato su STATUS_UPDATE. - In caso contrario, event_type rimane GENERIC_EVENT (valore predefinito).
	metadata.log_type	Il valore log_type è impostato come hardcoded su AVAYA_AURA.
	metadata.product_event_type	Il campo product_event_type viene compilato con il valore del campo event_name, se non è vuoto.
	metadata.product_name	Il valore di product_name è impostato come hardcoded su AVAYA AURA.
	metadata.vendor_name	Il valore vendor_name è impostato come hardcoded su AVAYA AURA.
	security_result.action	Il campo action all'interno della sezione security_result viene impostato in base alla seguente logica: - Se il campo summary contiene fail o failed (senza distinzione tra maiuscole e minuscole), l'azione viene impostata su BLOCK. - Se il campo di riepilogo contiene success (senza distinzione tra maiuscole e minuscole), l'azione viene impostata su ALLOW.
	security_result.severity_details	Il campo severity_details viene compilato con il valore del campo severity_details se non è vuoto.
timestamp.nanos	metadata.event_timestamp.nanos	Il valore dei nanosecondi del campo timestamp viene mappato direttamente al campo nanos nella sezione event_timestamp dei metadati nell'UDM.
timestamp.seconds	metadata.event_timestamp.seconds	Il valore dei secondi del campo timestamp viene mappato direttamente al campo seconds nella sezione event_timestamp dei metadati nell'UDM.
time	event.idm.read_only_udm.metadata.event_timestamp	Mappato dal log delle modifiche
src_ip	event.idm.read_only_udm.principal.ip e event.idm.read_only_udm.principal.asset.ip	Mappato dal log delle modifiche
src_port	event.idm.read_only_udm.principal.port	Mappato dal log delle modifiche
dst_ip	event.idm.read_only_udm.target.ip e event.idm.read_only_udm.target.asset.ip	Mappato dal log delle modifiche
dst_port	event.idm.read_only_udm.target.port	Mappato dal log delle modifiche
process_pid	event.idm.read_only_udm.principal.process.pid	Mappato dal log delle modifiche
principal_application	event.idm.read_only_udm.principal.application	Mappato dal log delle modifiche
network_protocol	event.idm.read_only_udm.network.ip_protocol	Mappato dal log delle modifiche
application_protocol_version	event.idm.read_only_udm.network.application_protocol_version	Mappato dal log delle modifiche
community_id	event.idm.read_only_udm.network.community_id	Mappato dal log delle modifiche
security_description	event.idm.read_only_udm.security_result.description	Mappato dal log delle modifiche
device_uptime	event.idm.read_only_udm.additional.fields	Mappato dal log delle modifiche
cmg_trap_subsystem	event.idm.read_only_udm.additional.fields	Mappato dal log delle modifiche
cmg_trap_onboard	event.idm.read_only_udm.additional.fields	Mappato dal log delle modifiche
cmg_trap_location	event.idm.read_only_udm.additional.fields	Mappato dal log delle modifiche
syslog_priority	event.idm.read_only_udm.additional.fields	Mappato dal log delle modifiche

Log delle modifiche

Visualizza il log delle modifiche per questo parser

Hai bisogno di ulteriore assistenza? Ricevi risposte dai membri della community e dai professionisti di Google SecOps.