Nas operações de segurança corporativa, eventos WAAP, ADC, AAM, health check, ações de administrador e GTM não devem ficar trancados dentro de um console de produto. As equipes SOC querem ver esses eventos em seus próprios sistemas SIEM, análise de logs e conformidade. Quando um fornecedor mantém logs em formatos proprietários ou difíceis de converter, a investigação de incidentes se fragmenta.
Diferentes plataformas SIEM vêm com expectativas de formato diferentes. Algumas equipes querem JSON para pesquisa e indexação, algumas dependem de CEF para parsers prontos, e outras preferem um fluxo syslog plainText simples. Produtos que impõem um único formato estendem os prazos de integração e empurram a normalização de logs para a organização.
Em ambientes multi-tenant ou separados por namespace, o streaming de logs se torna ainda mais sensível. Os logs de cada tenant devem chegar ao seu próprio SIEM, e os eventos de namespaces diferentes não devem se misturar. Uma única saída syslog global fica aquém tanto para isolamento quanto para auditabilidade em tais arquiteturas.
O volume de logs é outro desafio. Em cenários de health check de alta frequência ou eventos de segurança, enviar cada evento menor para o SIEM pode gerar custo e ruído. A filtragem em nível de fonte, o controle verbose de health check, múltiplos perfis e sampling onde apropriado precisam todos fazer parte do modelo de operações de log.
O TR7 Streaming de Logs para SIEM aborda tudo isso com perfis de transporte com escopo de namespace, syslog UDP/TCP, suporte a RFC3164/RFC5424, formatos de mensagem JSON/CEF/plainText e filtragem em nível de fonte — levando eventos da plataforma para o próprio pipeline SIEM da organização.
O TR7 trata o encaminhamento de logs não como uma única saída global, mas como um modelo de perfil gerenciado por namespace, formato, fonte e destino.
Um processo de transporte de logs dedicado pode ser executado para cada namespace de rede. Esse modelo evita que fluxos de logs de tenants diferentes se misturem em ambientes multi-tenant e garante que os logs de cada tenant cheguem ao seu próprio alvo SIEM.
As mensagens de log podem ser produzidas em JSON, CEF ou plainText. O JSON atende fluxos de trabalho de pesquisa e indexação, o CEF habilita parsers SIEM prontos, e o plainText cobre compatibilidade geral com syslog.
Cada perfil de transporte seleciona quais fontes de log encaminhar. Ações de administrador, eventos de health check, notificações, eventos GTM e eventos de segurança podem ser gerenciados por perfis separados conforme necessário.
Os perfis de transporte de log são sincronizados a partir dos dados de gerenciamento. Quando um perfil é adicionado, alterado ou removido, o processo de namespace relevante é atualizado sem reinicializar o sistema completo.
O Streaming de Logs para SIEM leva eventos da plataforma TR7 para a infraestrutura de logs externa via transportes syslog padrão e formatos de mensagem amigáveis ao SIEM.
O transporte UDP é um modelo de saída direto compatível com topologias syslog tradicionais. A porta syslog padrão 514 pode ser usada, ou uma porta diferente pode ser selecionada no nível do perfil. Ele fornece encaminhamento de logs de baixo overhead para ambientes LAN confiáveis. Como o UDP não oferece garantia de entrega por design, o TCP é preferível para ambientes críticos.
O transporte TCP é usado por equipes que querem um fluxo de log orientado a conexão para o alvo SIEM. O host de destino, a porta e o timeout podem ser definidos no perfil; um timeout TCP típico é de 10.000 ms. O TCP fornece entrega mais controlada do que o UDP, mas o comportamento da conexão deve ser monitorado quando o sistema de destino está lento.
O RFC3164 é suportado para integração com sistemas usando o formato syslog BSD tradicional. O campo syslogAppName do perfil pode ser usado como prefixo de mensagem; o valor padrão pode ser TR7_syslog_client. Ele fornece ampla compatibilidade para SIEMs mais antigos ou receptores syslog. Esse formato é uma escolha prática em ambientes que não requerem dados estruturados modernos.
O RFC5424 é o padrão syslog mais moderno e suporta campos de dados estruturados. Um perfil de log TR7 pode selecionar esse padrão para produzir mensagens syslog mais organizadas e processáveis por máquina. A análise de campos e a classificação de eventos se tornam mais consistentes no lado do SIEM. Combinado com payload JSON ou CEF, forma um modelo de integração robusto.
No formato JSON, campos como timestamp, source, severity, message e meta são facilmente processáveis por máquina. A pesquisa baseada em campos é simplificada para análise de logs, indexação e sistemas de consulta. As equipes SOC podem examinar eventos como campos analisados em vez de linhas de texto bruto. Esse formato é preferido em integrações com plataformas de log modernas.
As mensagens CEF são produzidas com a estrutura CEF:0|TR7|LogTransport|1.0|...|. Os valores de severidade são mapeados em uma escala de 0-10; níveis como info 3, warning 5, error 7 e critical 10 são usados. Os campos key-value podem ser processados por parsers prontos no lado do SIEM. Esse formato é adequado para equipes SOC que querem um fluxo CEF padrão para classificação e correlação de eventos.
O formato plainText produz campos de timestamp ISO, severity, source e message como texto legível por humanos. Pode ser implantado rapidamente em ambientes sem parsers complexos ou para integrações temporárias. Oferece alta legibilidade humana e é apropriado para alvos de log simples onde JSON ou CEF seria desnecessário.
userLogs cobre ações de administrador, hcLogs cobre eventos de health check, notificationLogs cobre notificações de sistema, e gtmLogs cobre eventos GTM. Cada perfil pode ser definido para enviar apenas as fontes que requer, de forma que apenas as classes de eventos relevantes cheguem ao SIEM. Os eventos de segurança WAAP também podem ser encaminhados para a infraestrutura de logs da organização por meio do mesmo pipeline de transporte.
Os logs de health check podem gerar alto volume em sistemas ocupados. Quando hcLogsVerbose é false, apenas os eventos de health check com uma condição stateChange são enviados. Essa abordagem reduz o ruído no SIEM e destaca apenas transições de estado de serviço significativas. O comportamento verbose pode ser habilitado temporariamente durante períodos de diagnóstico.
Mais de um perfil de transporte pode estar ativo dentro do mesmo namespace. Um perfil pode enviar em formato CEF para o SIEM do SOC enquanto outro encaminha em formato JSON para um sistema de análise de logs. Essa estrutura distribui o mesmo fluxo de logs para atender às necessidades de equipes diferentes. O cenário multi-alvo reduz a necessidade de implantar um roteador de logs externo separado.
O Streaming de Logs para SIEM é operado juntamente com formatação, sincronização de perfil, validação, isolamento de erros e comportamentos de sanitização de mensagens.
Os campos de vendor e product CEF são produzidos como TR7 / LogTransport / 1.0. A severidade é mapeada em uma escala de 0-10. Os campos de mensagem são estruturados como pares key-value legíveis por parsers SIEM.
O campo syslogAppName do perfil é usado como nome da aplicação nas mensagens syslog. O valor padrão pode ser TR7_syslog_client. Esse campo é importante para identificação de fonte e filtragem no lado do SIEM.
As alterações de perfil são agrupadas por namespace e aplicadas aos processos de transporte relevantes. Se um perfil antigo for removido, seu processo associado é encerrado. Perfis novos ou alterados podem ser incorporados ao fluxo de log ativo sem uma reinicialização.
Se o valor transportType não for syslog, o perfil não é admitido no pipeline de transporte syslog atual. Essa estrutura deixa espaço para expansão para diferentes tipos de transporte no futuro. O suporte atual é syslog UDP e TCP.
Os eventos de conexão e erro do cliente syslog são registrados por meio do logger interno. Os erros de conexão do SIEM de destino não derrubam o processo principal de gerenciamento. Os operadores podem monitorar problemas de conexão por meio de logs e status do perfil.
Se as mensagens provenientes da UI contiverem conteúdo HTML, o conteúdo de texto é extraído antes de ser enviado ao syslog. Isso é particularmente importante para segurança de campos e consistência de parsers no formato CEF. As mensagens de log são entregues ao SIEM de forma mais limpa e segura.
As equipes de segurança podem enviar eventos WAAP para o SIEM em formato CEF. Campos de regra, severidade, fonte e meta são processados por parsers SIEM. A equipe SOC vê os eventos em sua própria tela de correlação sem entrar na interface TR7.
As equipes de operações podem selecionar o formato JSON para encaminhar logs para uma plataforma de logs externa de forma indexada por campo. Os campos timestamp, source, severity e meta se tornam consultáveis. A análise de erros e a extração de tendências são simplificadas.
Um provedor de serviços gerenciados pode definir um namespace separado e um perfil de transporte de log separado para cada tenant. Os logs de cada tenant vão para seu próprio alvo SIEM. Os dados de tenants são impedidos de se misturarem no mesmo fluxo de logs.
As equipes de conformidade podem espelhar userLogs, notificationLogs e eventos de mudança de estado de health check para um SIEM central. Mesmo que os logs locais sejam excluídos ou rotacionados, os eventos críticos permanecem no sistema externo. As ações de administrador e os eventos de sistema podem ser revisados retroativamente durante auditorias.
Perfis com escopo de namespace, formatos JSON/CEF/plainText e filtragem em nível de fonte — vamos fazer um tour em uma configuração ao vivo no seu próprio ambiente.