Coletar registros do Avaya Aura
Neste documento, explicamos como ingerir registros do Avaya Aura no Google Security Operations usando o Bindplane. Primeiro, o analisador extrai campos de mensagens syslog brutas do Avaya Aura usando expressões regulares e o filtro "grok". Em seguida, ele mapeia os campos extraídos para um modelo de dados unificado (UDM, na sigla em inglês), normaliza valores como gravidade e identifica tipos de eventos específicos, como login ou logout do usuário, com base em palavras-chave.
Antes de começar
Verifique se você tem os pré-requisitos a seguir:
- Instância do Google SecOps
- Windows 2016 ou mais recente ou um host Linux com
systemd
- Se estiver executando por trás de um proxy, as portas do firewall estarão abertas.
- Acesso privilegiado ao Avaya Aura
Receber o arquivo de autenticação de ingestão do Google SecOps
- Faça login no console do Google SecOps.
- Acesse Configurações do SIEM > Agentes de coleta.
- Baixe o arquivo de autenticação de ingestão. Salve o arquivo de forma segura no sistema em que o Bindplane será instalado.
Receber o ID do cliente do Google SecOps
- Faça login no console do Google SecOps.
- Acesse Configurações do SIEM > Perfil.
- Copie e salve o ID do cliente na seção Detalhes da organização.
Instalar o agente do Bindplane
Instalação do Windows
- Abra o Prompt de Comando ou o PowerShell como administrador.
Execute este comando:
msiexec /i "https://github.com/observIQ/bindplane-agent/releases/latest/download/observiq-otel-collector.msi" /quiet
Instalação do Linux
- Abra um terminal com privilégios de root ou sudo.
Execute este comando:
sudo sh -c "$(curl -fsSlL https://github.com/observiq/bindplane-agent/releases/latest/download/install_unix.sh)" install_unix.sh
Outros recursos de instalação
Para mais opções de instalação, consulte o guia de instalação.
Configurar o agente do Bindplane para ingerir o Syslog e enviar ao Google SecOps
- Acesse o arquivo de configuração:
- Localize o arquivo
config.yaml
. Normalmente, ele fica no diretório/etc/bindplane-agent/
no Linux ou no diretório de instalação no Windows. - Abra o arquivo usando um editor de texto (por exemplo,
nano
,vi
ou Bloco de Notas).
- Localize o arquivo
Edite o arquivo
config.yaml
da seguinte forma:receivers: udolog: # Replace the port and IP address as required listen_address: "0.0.0.0:514" exporters: chronicle/chronicle_w_labels: compression: gzip # Adjust the path to the credentials file you downloaded in Step 1 creds: '/path/to/ingestion-authentication-file.json' # Replace with your actual customer ID from Step 2 customer_id: <customer_id> endpoint: malachiteingestion-pa.googleapis.com # Add optional ingestion labels for better organization ingestion_labels: log_type: 'AVAYA_AURA' raw_log_field: body service: pipelines: logs/source0__chronicle_w_labels-0: receivers: - udplog exporters: - chronicle/chronicle_w_labels
Substitua a porta e o endereço IP conforme necessário na sua infraestrutura.
Substitua
<customer_id>
pelo ID do cliente real.Atualize
/path/to/ingestion-authentication-file.json
para o caminho em que o arquivo de autenticação foi salvo na seção Receber arquivo de autenticação de ingestão do Google SecOps.
Reinicie o agente do Bindplane para aplicar as mudanças
Para reiniciar o agente do Bindplane no Linux, execute o seguinte comando:
sudo systemctl restart bindplane-agent
Para reiniciar o agente do Bindplane no Windows, use o console Serviços ou insira o seguinte comando:
net stop BindPlaneAgent && net start BindPlaneAgent
Configurar o Syslog no Avaya Aura
- Faça login no console do Avaya Aura.
- Acesse EM > Configuração do sistema > Configurações de registro > Syslog.
- Ative a Entrega de registros do SYSLOG.
- Clique em Adicionar.
- Informe os seguintes detalhes de configuração:
- Endereço do servidor: insira o endereço IP do agente do Bindplane.
- Porta: digite a porta de escuta do agente do Bindplane.
- Clique em Salvar.
- Clique em Confirmar.
- Reinicie o Avaya Aura.
Tabela de mapeamento da UDM
Campo de registro | Mapeamento da UDM | Lógica |
---|---|---|
data{}.@timestamp | metadata.event_timestamp | O carimbo de data/hora do evento é analisado do campo de dados usando o padrão grok e atribuído ao campo "event_timestamp" na seção de metadados da UDM. |
data{}.host | principal.hostname | O valor do host é extraído do campo de dados usando o padrão grok e atribuído ao campo de nome do host na seção principal da UDM. |
data{}.portal | security_result.about.resource.attribute.labels.value | O valor do portal é extraído do campo de dados usando o padrão grok e atribuído como o valor do rótulo Portal na seção about.resource.attribute.labels do security_result na UDM. |
data{}.prod_log_id | metadata.product_log_id | O valor "prod_log_id" é extraído do campo de dados usando o padrão grok e atribuído ao campo "product_log_id" na seção de metadados da UDM. |
data{}.sec_cat | security_result.category_details | O valor sec_cat é extraído do campo de dados usando o padrão grok e atribuído ao campo category_details na seção security_result da UDM. |
data{}.sec_desc | security_result.description | O valor "sec_desc" é extraído do campo de dados usando o padrão grok e atribuído ao campo "description" na seção "security_result" da UDM. |
data{}.severity | security_result.severity | O valor de gravidade é extraído do campo de dados usando o padrão grok. Se a gravidade for warn , fatal ou error (sem diferenciar maiúsculas de minúsculas), ela será mapeada para HIGH no campo security_result.severity do UDM. Caso contrário, se a gravidade for info (sem diferenciação de maiúsculas e minúsculas), ela será mapeada para LOW . |
data{}.summary | security_result.summary | O valor do resumo é extraído do campo de dados usando o padrão grok e atribuído ao campo de resumo na seção "security_result" da UDM. |
data{}.user_id | target.user.userid | O valor "user_id" é extraído do campo de dados usando o padrão grok e atribuído ao campo "userid" na seção "target.user" da UDM. |
extensions.auth.type | O campo "auth.type" é definido como AUTHTYPE_UNSPECIFIED se o campo "event_name" contiver log(in|on) ou logoff (sem diferenciação de maiúsculas e minúsculas) ou se o campo "summary" contiver login ou logoff (sem diferenciação de maiúsculas e minúsculas) e o campo "user_id" não estiver vazio. |
|
metadata.description | O campo "description" é preenchido com o valor do campo "desc" se ele não estiver vazio. | |
metadata.event_type | O campo "event_type" é determinado com base na seguinte lógica: - Se o campo "event_name" contiver log(in|on) ou o campo "summary" contiver login (sem diferenciação entre maiúsculas e minúsculas) e o campo "user_id" não estiver vazio, o "event_type" será definido como USER_LOGIN . - Se o campo "event_name" contiver logoff ou o campo "summary" contiver logoff (sem diferenciação entre maiúsculas e minúsculas) e o campo "user_id" não estiver vazio, o "event_type" será definido como USER_LOGOUT . - Se o campo "has_principal" for true , o "event_type" será definido como STATUS_UPDATE . - Caso contrário, o event_type vai permanecer como GENERIC_EVENT (valor padrão). |
|
metadata.log_type | O log_type está fixado no código como AVAYA_AURA . |
|
metadata.product_event_type | O campo "product_event_type" é preenchido com o valor do campo "event_name" se ele não estiver vazio. | |
metadata.product_name | O product_name está fixado no código como AVAYA AURA . |
|
metadata.vendor_name | O vendor_name está fixado no código como AVAYA AURA . |
|
security_result.action | O campo "action" na seção "security_result" é definido com base na seguinte lógica: - Se o campo "summary" contiver fail ou failed (sem diferenciação entre maiúsculas e minúsculas), a ação será definida como BLOCK . - Se o campo de resumo contiver success (sem distinção entre maiúsculas e minúsculas), a ação será definida como ALLOW . |
|
security_result.severity_details | O campo "severity_details" é preenchido com o valor do campo "severity_details" se ele não estiver vazio. | |
timestamp.nanos | metadata.event_timestamp.nanos | O valor de nanos do campo de registro de data e hora é mapeado diretamente para o campo de nanos na seção event_timestamp dos metadados na UDM. |
timestamp.seconds | metadata.event_timestamp.seconds | O valor de segundos do campo de carimbo de data/hora é mapeado diretamente para o campo de segundos na seção "event_timestamp" dos metadados na UDM. |
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.