Esta página foi traduzida pela API Cloud Translation.

Coletar registros do BeyondTrust Secure Remote Access

Compatível com:

Google SecOps SIEM

Este documento explica como coletar registros de acesso remoto seguro da BeyondTrust usando o Bindplane. O analisador processa dois formatos de syslog. O primeiro formato usa pares de chave-valor em uma mensagem estruturada, enquanto o segundo usa campos delimitados por pipe. O analisador extrai campos relevantes dos dois formatos e os mapeia para o UDM. Ele também realiza a categorização do tipo de evento com base nas palavras-chave extraídas e processa a lógica específica para eventos de login/saída e tipos de autenticação.

Antes de começar

Verifique se você tem uma instância do Google Security Operations.
Verifique se você está usando o Windows 2016 ou uma versão mais recente ou um host Linux com systemd.
Se estiver executando por trás de um proxy, verifique se as portas do firewall estão abertas.
Verifique se você tem acesso privilegiado a um BeyondTrust Secure Remote Access.

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.
Faça o download do arquivo de autenticação de transferência. Salve o arquivo com segurança no sistema em que o BindPlane será instalado.

Receber o ID de 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 raiz 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 este guia de instalação.

Configurar o agente do Bindplane para processar o Syslog e enviar ao Google SecOps

Acesse o arquivo de configuração:
1. Localize o arquivo config.yaml. Normalmente, ele está no diretório /etc/bindplane-agent/ no Linux ou no diretório de instalação no Windows.
2. Abra o arquivo usando um editor de texto (por exemplo, nano, vi ou Notepad).

Edite o arquivo config.yaml da seguinte forma:

receivers:
    udplog:
        # 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: BEYONDTRUST_REMOTE_ACCESS
            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 real do cliente.
Atualize /path/to/ingestion-authentication-file.json para o caminho em que o arquivo de autenticação foi salvo na seção Receber o 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 Services ou digite o seguinte comando:
```
net stop BindPlaneAgent && net start BindPlaneAgent
```

Configurar o suporte remoto da BeyondTrust

Faça login na IU da Web da BeyondTrust.
Selecione Dispositivo > Segurança > Administração do dispositivo.
Na seção Syslog, faça o seguinte:
- Formato da mensagem: selecione Formato legados BSD.
- Servidor syslog remoto: insira o endereço IP e a porta do Bindplane.
Clique em Enviar.

Tabela de mapeamento do UDM

Campo de registro	Mapeamento do UDM	Lógica
`datetime`	`metadata.event_timestamp`	O carimbo de data/hora é analisado do campo `datetime` usando o formato RFC3 339 se o campo `when` não estiver presente.
`deviceHost`	`target.hostname`	O valor de `deviceHost` é mapeado diretamente para `target.hostname`.
`dstHost`	`target.ip`	O valor de `dstHost` é mapeado diretamente para `target.ip` depois de ser validado como um endereço IP válido.
`dstPriv`	`additional.fields.[key=dstPriv].value.string_value`	O valor de `dstPriv` é colocado no campo `additional` com a chave `dstPriv`.
`dstUid`	`target.user.userid`	O valor de `dstUid` é mapeado diretamente para `target.user.userid`.
`dstUser`	`target.user.user_display_name`	O valor de `dstUser` é mapeado diretamente para `target.user.user_display_name`.
`eventName`	`metadata.event_type`	Se `eventName` for `login` (sem diferenciação entre maiúsculas e minúsculas), `metadata.event_type` será definido como `USER_LOGIN`. Se `eventName` for `logout` (sem diferenciação entre maiúsculas e minúsculas), `metadata.event_type` será definido como `USER_LOGOUT`. Caso contrário, se `eventName` não estiver vazio, `metadata.event_type` será definido como `USER_UNCATEGORIZED`. Se `eventName` estiver vazio e a mensagem corresponder ao segundo padrão de grok, `metadata.event_type` será definido como `GENERIC_EVENT`. Se `eventName` estiver vazio e a mensagem corresponder ao primeiro padrão de grok, `metadata.event_type` será definido como `GENERIC_EVENT`. Se `srcUid`, `userid` ou `who` não estiverem vazios, `metadata.event_type` será definido como `USER_CHANGE_PERMISSIONS`. Se `deviceHost` ou `site` não estiverem vazios, `metadata.event_type` será definido como `USER_UNCATEGORIZED`. Caso contrário, `metadata.event_type` será definido como `GENERIC_EVENT`.
`event_name`	`additional.fields.[key=event_name].value.string_value`	O valor de `event_name` é colocado no campo `additional` com a chave `event_name`.
`event_name`	`metadata.product_event_type`	O valor de `event_name` é usado com o campo `id` para preencher `metadata.product_event_type` no formato `[`id`] -`event_name".
`externalKeyLabel`	`additional.fields.[key=externalKeyLabel].value.string_value`	O valor de `externalKeyLabel` é colocado no campo `additional` com a chave `externalKeyLabel`.
`id`	`metadata.product_event_type`	O valor de `id` é usado com o campo `event_name` para preencher `metadata.product_event_type` no formato `[`id`] -`event_name".
`jumpGroupId`	`additional.fields.[key=jumpGroupId].value.string_value`	O valor de `jumpGroupId` é colocado no campo `additional` com a chave `jumpGroupId`.
`jumpGroupName`	`additional.fields.[key=jumpGroupName].value.string_value`	O valor de `jumpGroupName` é colocado no campo `additional` com a chave `jumpGroupName`.
`jumpGroupType`	`additional.fields.[key=jumpGroupType].value.string_value`	O valor de `jumpGroupType` é colocado no campo `additional` com a chave `jumpGroupType`.
`jumpointId`	`additional.fields.[key=jumpointId].value.string_value`	O valor de `jumpointId` é colocado no campo `additional` com a chave `jumpointId`.
`jumpointName`	`additional.fields.[key=jumpointName].value.string_value`	O valor de `jumpointName` é colocado no campo `additional` com a chave `jumpointName`.
`kv_data`	Vários campos do UDM	O campo `kv_data` é analisado em pares de chave-valor, que são mapeados para vários campos do UDM com base nas chaves (por exemplo, `eventName`, `when`, `who`, `who_ip`, `site`, `target`, `status`, `reason`).
`kvdata`	Vários campos do UDM	O campo `kvdata` é analisado em pares de chave-valor, que são mapeados para vários campos do UDM com base nas chaves (por exemplo, `msg`, `srcUser`, `srcUid`, `srcHost`, `dstUser`, `dstUid`, `dstHost`, `sessionId`, `jumpointId`, `jumpointName`, `jumpGroupId`, `jumpGroupName`, `jumpGroupType`, `externalKeyLabel`, `dstPriv`).
`message`	Vários campos do UDM	O campo `message` é analisado usando padrões grok para extrair vários campos, que são mapeados para campos do UDM.
`msg`	`metadata.description`	O valor de `msg` é mapeado diretamente para `metadata.description`.
`product_event_type`	`metadata.product_event_type`	O valor de `product_event_type` é mapeado diretamente para `metadata.product_event_type`.
`product_log_id`	`metadata.product_log_id`	O valor de `product_log_id` é mapeado diretamente para `metadata.product_log_id`.
`process_id`	`principal.process.pid`	O valor de `process_id` é mapeado diretamente para `principal.process.pid`.
`reason`	`security_result.description`	O valor de `reason` é mapeado diretamente para `security_result.description`.
`segment_number`	`additional.fields.[key=segment_number].value.string_value`	O valor de `segment_number` é colocado no campo `additional` com a chave `segment_number`.
`sessionId`	`network.session_id`	O valor de `sessionId` é mapeado diretamente para `network.session_id`.
`site`	`target.hostname`	O valor de `site` é mapeado diretamente para `target.hostname`.
`site_id`	`additional.fields.[key=site_id].value.string_value`	O valor de `site_id` é colocado no campo `additional` com a chave `site_id`.
`srcHost`	`principal.ip`	O valor de `srcHost` é mapeado diretamente para `principal.ip` depois de ser validado como um endereço IP válido.
`srcUid`	`principal.user.userid`	O valor de `srcUid` é mapeado diretamente para `principal.user.userid`.
`srcUser`	`principal.user.user_display_name`	O valor de `srcUser` é mapeado diretamente para `principal.user.user_display_name`.
`status`	`security_result.action`	Se `status` for `failure` (sem diferenciação entre maiúsculas e minúsculas), `security_result.action` será definido como `BLOCK`. Caso contrário, `security_result.action` será definido como `ALLOW`.
`status`	`security_result.action_details`	O valor de `status` é mapeado diretamente para `security_result.action_details`.
`target`	`target.application`	O valor de `target` é mapeado diretamente para `target.application`. `rep_client` foi substituído por `Representative Console` e `web/login` foi substituído por `Web/Login`.
`target`	`extensions.auth.type`	Se `target` for `rep_client`, `extensions.auth.type` será definido como `MACHINE`. Se `target` for `web/login`, `extensions.auth.type` será definido como `SSO`. Caso contrário, `extensions.auth.type` será definido como `AUTHTYPE_UNSPECIFIED`.
`timestamp`	`metadata.event_timestamp`	O `timestamp` do registro bruto é usado como substituto se nem `datetime` nem `when` estiverem presentes.
`total_segments`	`additional.fields.[key=total_segments].value.string_value`	O valor de `total_segments` é colocado no campo `additional` com a chave `total_segments`.
`device_product`	`additional.fields.[key=device_product].value.string_value`	O valor de `device_product` é colocado no campo `additional` com a chave `device_product`.
`device_vendor`	`additional.fields.[key=device_vendor].value.string_value`	O valor de `device_vendor` é colocado no campo `additional` com a chave `device_vendor`.
`device_version`	`metadata.product_version`	O valor de `device_version` é mapeado diretamente para `metadata.product_version`.
`when`	`metadata.event_timestamp`	O carimbo de data/hora é analisado do campo `when` usando o formato UNIX, se presente.
`who`	`principal.user.userid`	Se o campo `who` corresponder ao padrão de regex, o `userid` extraído será mapeado para `principal.user.userid`. Caso contrário, todo o campo `who` será mapeado para `principal.user.userid`.
`who`	`principal.user.user_display_name`	Se o campo `who` corresponder ao padrão de regex, o `user_display_name` extraído será mapeado para `principal.user.user_display_name`.
`who_ip`	`principal.ip`	O valor de `who_ip` é mapeado diretamente para `principal.ip`.
(Parser Logic)	`metadata.log_type`	O tipo de registro está definido como `BEYONDTRUST_REMOTE_ACCESS`.
(Parser Logic)	`metadata.product_name`	O nome do produto é definido como `BeyondTrust Secure Remote Access`.
(Parser Logic)	`metadata.vendor_name`	O nome do fornecedor está definido como `BeyondTrust`.
(Parser Logic)	`security_result.summary`	O valor é derivado usando o formato `User %{eventName}`.
(Parser Logic)	`extensions.auth.mechanism`	Se `method` contiver `using password`, o mecanismo será definido como `USERNAME_PASSWORD`. Se `method` contiver `using elevate`, o mecanismo será definido como `REMOTE`.

Alterações

2022-09-30

Melhoria:

O grok foi escrito para analisar syslogs não analisados.
device_vendor foi mapeado para additional.fields.
event_name foi mapeado para additional.fields.
device_product foi mapeado para additional.fields.
externalKeyLabel foi mapeado para additional.fields.
dstPriv foi mapeado para additional.fields.
filePath foi mapeado para target.file.full_path.
fsize foi mapeado para target.file.size.

2022-07-14

Parser recém-criado.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.