Dans les opérations de sécurité d'entreprise, les événements WAAP, ADC, AAM, health check, actions admin et GTM ne doivent pas rester enfermés dans une console produit. Les équipes SOC veulent voir ces événements dans leur propre SIEM, leur analytique de logs et leurs systèmes de conformité. Lorsqu'un éditeur conserve les logs dans des formats propriétaires ou difficiles à convertir, l'investigation des incidents devient fragmentée.
Différentes plateformes SIEM ont des attentes de format différentes. Certaines équipes veulent JSON pour la recherche et l'indexation, d'autres s'appuient sur CEF pour les parsers prêts à l'emploi, et d'autres préfèrent un flux syslog plainText simple. Les produits qui imposent un format unique prolongent les délais d'intégration et repoussent la normalisation des logs sur l'organisation.
Dans les environnements multi-locataires ou séparés par namespace, le streaming de logs devient encore plus sensible. Les logs de chaque locataire doivent atteindre leur propre SIEM, et les événements de différents namespaces ne doivent pas se mélanger. Un seul output syslog global est insuffisant à la fois pour l'isolation et l'auditabilité dans de telles architectures.
Le volume de logs est un autre défi. Dans des scénarios à haute fréquence de health check ou d'événements de sécurité, envoyer chaque événement mineur au SIEM peut générer des coûts et du bruit. Le filtrage au niveau des sources, le contrôle verbose du health check, les profils multiples et le sampling le cas échéant doivent tous faire partie du modèle d'opérations de logs.
TR7 Streaming de Logs SIEM répond à tout cela avec des profils de transport délimités par namespace, syslog UDP/TCP, prise en charge RFC3164/RFC5424, formats de messages JSON/CEF/plainText et filtrage au niveau des sources — portant les événements de plateforme vers le propre pipeline SIEM de l'organisation.
TR7 traite le transfert de logs non pas comme un seul output global, mais comme un modèle de profil géré par namespace, format, source et destination.
Un processus de transport de logs dédié peut s'exécuter pour chaque namespace réseau. Ce modèle empêche les flux de logs de différents locataires de se mélanger dans les environnements multi-locataires et garantit que les logs de chaque locataire atteignent sa propre cible SIEM.
Les messages de log peuvent être produits en JSON, CEF ou plainText. JSON sert les workflows de recherche et d'indexation, CEF active les parsers SIEM prêts à l'emploi, et plainText couvre la compatibilité syslog générale.
Chaque profil de transport sélectionne les sources de logs à transférer. Les actions admin, les événements de health check, les notifications, les événements GTM et les événements de sécurité peuvent chacun être gérés via des profils séparés selon les besoins.
Les profils de transport de logs sont synchronisés depuis les données de gestion. Lorsqu'un profil est ajouté, modifié ou supprimé, le processus de namespace concerné est mis à jour sans redémarrer le système complet.
Le Streaming de Logs SIEM transporte les événements de plateforme TR7 vers l'infrastructure de logs externe via des transports syslog standard et des formats de messages adaptés aux SIEM.
Le transport UDP est un modèle d'output simple compatible avec les topologies syslog traditionnelles. Le port syslog par défaut 514 peut être utilisé, ou un port différent peut être sélectionné au niveau du profil. Il offre un transfert de logs à faible surcharge pour les environnements LAN fiables. UDP n'offrant aucune garantie de livraison par conception, TCP est préférable pour les environnements critiques.
Le transport TCP est utilisé par les équipes qui souhaitent un flux de logs orienté connexion vers la cible SIEM. L'hôte cible, le port et le timeout peuvent être définis dans le profil ; un timeout TCP typique est de 10 000 ms. TCP offre une livraison plus contrôlée qu'UDP, mais le comportement de connexion doit être supervisé lorsque le système cible est lent.
RFC3164 est pris en charge pour l'intégration avec les systèmes utilisant le format BSD syslog traditionnel. Le champ de profil syslogAppName peut être utilisé comme préfixe de message ; la valeur par défaut peut être TR7_syslog_client. Il fournit une large compatibilité pour les anciens SIEM ou récepteurs syslog. Ce format est un choix pratique dans les environnements qui ne nécessitent pas de données structurées modernes.
RFC5424 est le standard syslog plus moderne et prend en charge les champs de données structurées. Un profil de log TR7 peut sélectionner ce standard pour produire des messages syslog plus organisés et traçables par machine. L'analyse des champs et la classification des événements deviennent plus cohérentes côté SIEM. Combiné avec un payload JSON ou CEF, il forme un modèle d'intégration robuste.
Au format JSON, les champs tels que timestamp, source, severity, message et meta sont facilement traçables par machine. La recherche basée sur les champs est simplifiée pour l'analytique de logs, l'indexation et les systèmes de requête. Les équipes SOC peuvent examiner les événements comme des champs parsés plutôt que des lignes de texte brut. Ce format est préféré dans les intégrations avec les plateformes de logs modernes.
Les messages CEF sont produits avec la structure CEF:0|TR7|LogTransport|1.0|...|. Les valeurs de sévérité sont mappées sur une échelle de 0 à 10 ; des niveaux tels que info 3, warning 5, error 7 et critical 10 sont utilisés. Les champs clé-valeur peuvent être traités par des parsers prêts à l'emploi côté SIEM. Ce format convient aux équipes SOC qui souhaitent un flux CEF standard pour la classification et la corrélation d'événements.
Le format PlainText produit les champs horodatage ISO, sévérité, source et message sous forme de texte lisible par l'humain. Il peut être déployé rapidement dans les environnements sans parsers complexes ou pour des intégrations temporaires. Il offre une haute lisibilité humaine et convient aux cibles de logs simples où JSON ou CEF serait superflu.
userLogs couvre les actions admin, hcLogs couvre les événements de health check, notificationLogs couvre les notifications système, et gtmLogs couvre les événements GTM. Chaque profil peut être défini pour n'envoyer que les sources dont il a besoin, de sorte que seules les classes d'événements pertinentes atteignent le SIEM. Les événements de sécurité WAAP peuvent également être transférés vers l'infrastructure de logs de l'organisation via le même pipeline de transport.
Les logs de health check peuvent générer un volume élevé sur les systèmes chargés. Lorsque hcLogsVerbose est false, seuls les événements de health check avec une condition stateChange sont envoyés. Cette approche réduit le bruit SIEM et met en évidence uniquement les transitions d'état de service significatives. Le comportement verbose peut être activé temporairement pendant les périodes de dépannage.
Plus d'un profil de transport peut être actif dans le même namespace. Un profil peut envoyer au format CEF vers le SIEM SOC tandis qu'un autre transfère au format JSON vers un système d'analytique de logs. Cette structure distribue en éventail le même flux de logs pour répondre aux besoins de différentes équipes. Le scénario multi-cible réduit le besoin de déployer un routeur de logs externe séparé.
Le Streaming de Logs SIEM est exploité conjointement avec la mise en forme, la synchronisation des profils, la validation, l'isolation des erreurs et les comportements de nettoyage des messages.
Les champs vendor et product CEF sont produits comme TR7 / LogTransport / 1.0. La sévérité est mappée sur une échelle de 0 à 10. Les champs de message sont structurés comme des paires clé-valeur lisibles par les parsers SIEM.
Le champ de profil syslogAppName est utilisé comme nom d'application dans les messages syslog. La valeur par défaut peut être TR7_syslog_client. Ce champ est important pour l'identification des sources et le filtrage côté SIEM.
Les changements de profil sont groupés par namespace et appliqués aux processus de transport concernés. Si un ancien profil est supprimé, son processus associé est terminé. Les profils nouveaux ou modifiés peuvent être intégrés dans le flux de logs actif sans redémarrage.
Si la valeur transportType n'est pas syslog, le profil n'est pas admis dans le pipeline de transport syslog actuel. Cette structure laisse de la place pour l'extension à différents types de transport à l'avenir. La prise en charge actuelle est UDP et TCP syslog.
Les événements de connexion et d'erreur du client syslog sont enregistrés via le logger interne. Les erreurs de connexion au SIEM cible n'interrompent pas le processus de gestion principal. Les opérateurs peuvent superviser les problèmes de connexion via les logs et l'état des profils.
Si les messages provenant de l'UI contiennent du contenu HTML, le contenu texte est extrait avant d'être envoyé à syslog. C'est particulièrement important pour la sécurité des champs et la cohérence des parsers au format CEF. Les messages de log sont livrés au SIEM sous une forme plus propre et plus sûre.
Les équipes sécurité peuvent envoyer les événements WAAP au SIEM au format CEF. Les champs règle, sévérité, source et meta sont traités par les parsers SIEM. L'équipe SOC voit les événements sur son propre écran de corrélation sans entrer dans l'interface TR7.
Les équipes opérationnelles peuvent sélectionner le format JSON pour transférer les logs vers une plateforme de logs externe sous forme indexée par champ. Les champs timestamp, source, severity et meta deviennent interrogeables. L'analyse d'erreurs et l'extraction de tendances sont simplifiées.
Un fournisseur de services managés peut définir un namespace séparé et un profil de transport de logs séparé pour chaque locataire. Les logs de chaque locataire vont vers sa propre cible SIEM. Les données des locataires sont empêchées de se mélanger dans le même flux de logs.
Les équipes de conformité peuvent mettre en miroir les userLogs, notificationLogs et les événements de changement d'état de health check vers un SIEM central. Même si les logs locaux sont supprimés ou tournés, les événements critiques restent dans le système externe. Les actions admin et les événements système peuvent être examinés rétrospectivement lors des audits.
Profils délimités par namespace, formats JSON/CEF/plainText et filtrage au niveau des sources — parcourons ensemble une configuration en direct dans votre propre environnement.