Se eventos de segurança e tráfego não fluem para um SIEM em formato padrão, o SOC vê o quadro completo tarde demais.
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.
Nossa abordagem
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 separado por namespace fornece isolamento de logs
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.
Um pool de formatos se adapta a diferentes expectativas de 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.
A filtragem de fonte em nível de perfil reduz ruído desnecessário de logs
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.
A sincronização orientada por banco de dados aplica alterações de perfil sem reinicialização
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.
Capacidades
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 fornece um fluxo syslog rápido e simples
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 fornece um fluxo de log conectado e mais controlado
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 suporte a RFC3164 garante compatibilidade com receptores syslog legados
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 suporte a RFC5424 funciona com arquiteturas syslog modernas
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.
O formato de mensagem JSON é bem adequado para sistemas de pesquisa e indexação
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.
O formato CEF permite integração rápida com parsers SIEM prontos
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 é usado em ambientes que requerem compatibilidade syslog básica
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.
Quatro fontes de log principais podem ser selecionadas por perfil
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.
O controle verbose de health check gerencia o volume de logs
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.
Múltiplos perfis podem enviar o mesmo log para destinos diferentes em formatos diferentes
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.
Profundidade operacional
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.
Modelo de formatação CEF
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.
Configuração do nome da aplicação
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.
Sincronização de perfil
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.
Validação de perfil
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.
Isolamento de erros
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.
Sanitização de HTML
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.
Quando usar
Encaminhamento de eventos WAAP para o sistema SOC em formato CEF
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.
Alimentando uma plataforma de pesquisa e análise com um fluxo de logs JSON
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.
Separação de SIEM em nível de namespace em ambientes multi-tenant
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.
Exportando eventos de administrador e sistema para conformidade
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.
Perguntas frequentes
Quais fontes de log podem ser incluídas em um perfil de transporte?
Qual é a diferença entre os formatos de mensagem CEF e JSON?
Múltiplos perfis podem ser executados no mesmo namespace simultaneamente?
Como os volumes de log de health check são mantidos sob controle?
Quando o transporte TCP é preferido ao UDP?
Como as alterações de perfil são aplicadas sem tempo de inatividade?
Deixe seu SIEM ler cada evento da plataforma
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.