Sophos Firewall Syslog veilig naar een SIEM sturen

Met Syslog verstuurt een Sophos Firewall gebeurtenissen naar een externe logserver, SIEM of SOC. Om de integratie echt bruikbaar te maken, moeten vier zaken op elkaar aansluiten: transport, logselectie, indeling en parser. Dit artikel begint daarom direct met de configuratie en laat vervolgens zien hoe ontbrekende of verkeerd geïnterpreteerde logs worden herkend.

De lokale Log viewer blijft belangrijk voor live-analyse. Central Firewall Reporting is geschikt voor rapporten in Sophos Fusion (voorheen Sophos Central); Syslog is de juiste keuze voor eigen opslag, correlatie tussen verschillende leveranciers en SIEM-detectie.

De Syslog-server configureren

Vooraf moeten het doel-IP-adres of de FQDN, de poort, de verwachte logindeling en een geschikte parser vaststaan. De firewall heeft een route naar de collector nodig en beide systemen een correct werkende tijdbron. SFOS gebruikt voor Syslog normaal UDP 514. Dit scherm heeft geen afzonderlijke transportkeuze: Secure log transmission schakelt TLS-versleutelde overdracht in of uit. In het officiële TLS-voorbeeld van Sophos voor syslog-ng wordt poort 6514 gebruikt; poort en listener moeten altijd overeenkomen met de eigen collector.

Open System services > Log settings.
Selecteer Add.
Voer een eenduidige naam in, zoals siem-primary.
Voer de collector in onder IP address/domain.
Selecteer Port, Facility, Severity level en Format passend bij het doelsysteem.
Activeer Secure log transmission als de TLS-collector is voorbereid.
Sla de configuratie op.
Activeer onder Log settings de gewenste logtypen in de kolom van deze Syslog-server.

SFOS ondersteunt maximaal vijf externe Syslog-servers. Meerdere doelen zijn nuttig als ze verschillende taken hebben, zoals een lokaal archief en een MDR-collector. Alle logs zonder onderscheid naar elk doel sturen verhoogt daarentegen het volume, de kosten en het privacyrisico.

Facility, Severity en indeling

Facility: De opties omvatten DAEMON, KERNEL, USER en LOCAL0 tot en met LOCAL7. Zo kunnen LOCAL1 en LOCAL2 bijvoorbeeld aan twee firewalls worden toegewezen. Houd de toewijzing gelijk in de collector en de beheerdocumentatie.
Severity level: De selectie is de minimale ernst. Error verstuurt ook Critical, Alert en Emergency, maar geen Information- of Notice-gebeurtenissen. Debug omvat alle niveaus. Een te hoge minimumwaarde kan aanmeldingen en normale operationele gebeurtenissen verbergen.
Format: De beschikbare opties zijn Standard syslog protocol en Device standard format (legacy). Doorslaggevend is welke indeling de SIEM-parser verwacht. Een latere wijziging kan zoekopdrachten, dashboards en detectieregels verstoren.

Facilities geven de herkomst van een log aan: DAEMON staat voor processen die als dienst draaien, KERNEL voor kernelprocessen en USER voor processen gestart door aangemelde gebruikers. LOCAL0 tot en met LOCAL7 zijn bedoeld voor eigen toewijzingen. Bij Severity is Alert ernstiger dan Critical en vereist het direct handelen. Standard syslog protocol heette eerder Central Reporting Format; Central Reporting gebruikt uitsluitend deze indeling. Bij Device standard format (legacy) varieert het aantal gegevensvelden per module.

Secure log transmission

TLS is zinvol voor productieverbindingen via onbetrouwbare of gedeelde netwerken, omdat logs interne adressen, gebruikersnamen, URL’s en beveiligingsgebeurtenissen kunnen bevatten. Alleen het selectievakje inschakelen is echter niet voldoende: de collector moet TLS op de geselecteerde poort accepteren en beide kanten moeten de certificaten kunnen valideren.

Voor de door Sophos gedocumenteerde Secure Syslog-verbinding geldt:

Het servercertificaat van de collector en de certificaatketen moeten door de firewall worden vertrouwd.
De geconfigureerde FQDN moet met het certificaat overeenkomen. Zonder LINCE controleert SFOS de Common Name; met LINCE mag de Common Name of Subject Alternative Name overeenkomen.
Download onder Certificates > Certificate authorities de Sophos-CA Default. De collector moet het geëxtraheerde Default.pem vertrouwen, omdat Sophos deze CA voor zijn kant van de verbinding gebruikt.
Activeer pas daarna Secure log transmission met de voorbereide TLS-poort.

In het officiële syslog-ng-voorbeeld staan Default.pem en de externe CA in de CA-directory van de collector; peer_verify(required-trusted) dwingt de certificaatvalidatie af. Andere collectorproducten hebben daarvoor hun eigen truststores. Een FQDN die alleen in de SAN staat, werkt niet zonder LINCE, en een ingevoerd IP-adres komt niet overeen met een certificaat dat uitsluitend DNS-namen bevat.

Controleer vóór het inschakelen van LINCE voor dit doel de certificeringsgrens, toegestane algoritmen en SSH-herstart van LINCE-modus. De modus is niet alleen een syslogschakelaar en mag niet zonder onafhankelijke beheerstoegang worden ingeschakeld.

Als een cloud-SIEM deze methode niet rechtstreeks ondersteunt, kan de firewall de logs intern naar een lokale collector sturen, die ze vervolgens versleuteld doorstuurt. Een onversleuteld traject moet kort, gesegmenteerd en gedocumenteerd zijn.

Een TLS-collector met syslog-ng voorbereiden

Dit voorbeeld vereist een Linux-collector met syslog-ng, ingeschakelde TLS-ondersteuning en een servercertificaat van een externe CA. De firewall is de verzendende client. ExternalCertificate.pem is het servercertificaat, ExternalPrivateKey.key de bijbehorende privésleutel en ExternalCA.pem de uitgevende CA. Dit zijn voorbeeldnamen; pas paden en certificaten aan de eigen collector aan. Bescherm de privésleutel op de collector; de privésleutel van de firewall-CA is hiervoor niet nodig.

Controleer de bestaande CA onder Certificates > Certificate authorities > Default. De naam kan niet worden gewijzigd. Country name, State en Locality name beschrijven land, regio en plaats; Organization name en Organization unit name de eigenaar en afdeling. Common name bevat een naam of FQDN en Email address een contact. Private key password kan een bestaand CA-wachtwoord wijzigen. Key type biedt RSA of Elliptic curve: kies Key length bij RSA of Curve name bij Elliptic curve; Secure hash bepaalt het hash-algoritme. Key length is de RSA-sleutellengte in bits; grotere sleutels bieden meer veiligheidsmarge, maar vereisen meer rekenwerk. Voorbeelden van CA-identiteit zijn Example AG, IT Security en fw01.example.com; vervang deze door de eigenaar, afdeling en goedgekeurde naamgevingsconventie van de eigen omgeving. Deze CA-attributen zijn niet het servercertificaat van de collector en vervangen de passende FQDN niet.

Bescherm de bestaande CA: Wijzig of regenereer de Default-CA niet uitsluitend voor Syslog. Plan noodzakelijke CA-wijzigingen met een back-up, onderhoudsvenster en controles van afhankelijke diensten; de Default-CA vernieuwen legt de gevolgen uit. Instellingen bijwerken met Save regenereert de Default-CA automatisch en verandert het vertrouwensanker. Sla alleen goedgekeurde wijzigingen op tijdens het geplande onderhoudsvenster. Download daarna via de downloadknop het tar.gz-archief en pak het openbare CA-certificaat Default.pem uit.

Plaats op de collector Default.pem en ExternalCA.pem in /etc/syslog-ng/ca.d/, en ExternalCertificate.pem en ExternalPrivateKey.key in /etc/syslog-ng/cert.d/. Controleer eerst directories en bestaande bestanden; overschrijf certificaten niet ongepland. Alleen de verantwoordelijke dienst en bevoegde beheerders mogen de privésleutel lezen.

Voer deze opdrachten uit op de Linux-collector, niet in de SFOS Device Console. De eerste leest het certificaat. De tweede maakt een symbolische link in de CA-directory en vereist daar schrijfrechten:

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Gebruik de werkelijk geretourneerde hash, niet blind 52412b66. Voor de voorbeelduitvoer 52412b66 is de opdracht:

ln -s Default.pem 52412b66.0

Controleer bij een bestaande .0-vermelding eerst het doel in plaats van deze te overschrijven. Controleer hash en koppeling opnieuw na een certificaatwijziging.

Dit syslog-ng.conf-voorbeeld toont een TLS-listener en twee lokale uitvoerbestanden. @version: 3.15 is de versiedeclaratie van het gedocumenteerde voorbeeld, geen aanbeveling voor een verouderde installatie. Controleer syntax, modules en declaratie tegen de geïnstalleerde syslog-ng-versie vóór gebruik. Integreer dit in de bestaande configuratie zonder de andere bronnen en doelen te vervangen.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 bindt alle IPv4-adressen van de collector. Gebruik in productie bij voorkeur het bedoelde ontvangstadres en beperk TCP 6514 via de hostfirewall tot de verzendende firewalls. Poort 6514 moet overeenkomen met de SFOS-vermelding. key-file en cert-file verwijzen naar de serveridentiteit en ca-dir naar de twee CA-certificaten; schakel peer_verify(required-trusted) niet uit om fouten te omzeilen. De bestandsdoelen leveren ruwe logs en aanvullende key-value-uitvoer met millisecondeprecisie; pas paden, rechten, rotatie en opslag aan het beheer aan.

Controleer de configuratie vóór het starten met de validatiefunctie van de geïnstalleerde versie. Start de dienst of pas wijzigingen gecontroleerd toe in een goedgekeurd venster; herstel bij problemen de geback-upte configuratie. Stel vervolgens in SFOS onder System services > Log settings > Add de collector, poort 6514 en Secure log transmission in en klik op Save. Selecteer de benodigde modules in de serverkolom. Succes betekent een TLS-verbinding zonder vertrouwensfouten, een bewust gegenereerde firewallgebeurtenis in de uitvoerbestanden en correct geparste SIEM-velden.

Logtypen en zichtbaarheid vastleggen

Het doel wordt in twee stappen geactiveerd:

De betreffende regel of functie moet de gebeurtenis genereren. Voor firewallregels is daarvoor Log firewall traffic vereist en voor SSL/TLS-inspectieregels Log connections.
Onder System services > Log settings moet het bijbehorende logtype in de kolom van de Syslog-server zijn geselecteerd.

Als een van beide stappen ontbreekt, kan de collector de gebeurtenis niet ontvangen. Voor een pilot volstaat aanvankelijk een bewust kleine set:

Firewall en Events: Regelgebeurtenissen, activiteiten van beheerders en gebruikers en gebeurtenissen voor authenticatie, VPN, DHCP en DNS.
IPS, Content filtering, Web server protection en Zero-day protection: Beveiligings- en beleidsbeslissingen.
Active threat response: Treffers van MDR, NDR Essentials, Sophos X-Ops en Third-Party Threat Feeds.
System health, Wireless, Heartbeat en SD-WAN: Aanvullende operationele status wanneer deze modules worden gebruikt.

Voeg pas meer modules toe als er een zoek-, alarmerings- of auditdoel bestaat. Wie DoS-gebeurtenissen analyseert, moet ook de configuratie voor spoofing- en DoS-bescherming controleren. Voor Third-Party Threat Feeds en NDR en Active Threat Response zijn naast het logtransport concrete zoekopdrachten en alarmen nodig.

ATR-reikwijdte: Schakel logging van externe bronnen alleen in voor aantoonbaar ondersteunde combinaties van module en verkeerspad. De ATR-tekst en SVG-verkeersmatrix van Sophos spreken elkaar tegen over X-Ops-matchrichtingen; dit conflict blijft onopgelost. Uitspraken over MDR, NDR of feeds van derden bewijzen geen gelijkwaardige X-Ops-ondersteuning. Houd beperkende firewall-, DNAT/WAF- en Device Access-controles onafhankelijk van het betwiste feedgedrag. Betwiste gevallen vereisen geautoriseerde, gecontroleerde verificatie van de module, matchrichting, logs en daadwerkelijke werking, plus betrouwbare verduidelijking; tot die tijd mag de bescherming niet van dat gedrag afhangen. NDR en Active Threat Response biedt de veilige context.

XML-API: collector, logselectie en suppressie gescheiden houden

Wie Syslog via de XML-API beheert, moet deze drie niveaus afzonderlijk behandelen. De Add-/Update-voorbeelden voor SFOS 22.0 en SFOS 23.0 maken onderscheid tussen:

Collectorinstellingen: Doeladres, poort, TLS, Facility, Severity en indeling bepalen de ontvanger en de overdracht. Een aangemaakte of geselecteerde collector activeert niet automatisch alle logs.
Verzending per groep en submodule: Binnen LogSettings staat SendLogs voor het groepsniveau; afzonderlijke submodules kunnen deze selectie overschrijven. Het voorbeeld waarschuwt er uitdrukkelijk voor om SendLogs op te geven wanneer alle submodules zijn vermeld. Vat deze vormen daarom niet samen als een algemene activering. Bij PolicyRules noemt het commentaar in het voorbeeld Disable als standaardwaarde; daaruit volgt geen automatische inschakeling van alle regelgebeurtenissen. Logging in de betreffende regel blijft daarnaast vereist.
Suppressie: Log_suppress wordt in het voorbeeld afzonderlijk van de verzending vermeld. Het samenvoegen van herhaalde gebeurtenissen is niet hetzelfde als het selecteren van hun ontvanger of een Severity-filter.

De parametertabel vermeldt Name tweemaal en beschrijft de tweede rij als suppressiestatus; bovendien staat daar letterlijk uiui als standaardwaarde. Dit is geen betrouwbare basis voor een operationele standaardwaarde of een stilzwijgende hernoeming van het veld. Leid hieruit geen volledige suppressiepayload af; verduidelijk onduidelijke API-velden eerst aan de hand van de help voor de specifieke build of met Sophos Support. Genereer vóór en na een goedgekeurde wijziging dezelfde representatieve gebeurtenissen en vergelijk de ruwe logs op de collector, de parservelden in het SIEM en de verwachte logtypen en log_occurrence. Een bestaande verbinding alleen bewijst niet dat de juiste logs zijn geselecteerd.

Veelvoorkomende valkuilen voor zichtbaarheid

Log Suppression: SFOS kan identieke opeenvolgende firewallgebeurtenissen samenvoegen. Dit is van invloed op Log Viewer, Sophos Fusion en Syslog. Parsers en detecties moeten daarom ook rekening houden met log_occurrence.
Active Threat Response: Remote Source Match voor inkomend DNAT- of WAF-verkeer is niet standaard actief. Zonder deze selectie ontbreken de bijbehorende brontreffers op ondersteunde module-/verkeerspaden. Houd ook bij onderzoek naar ontbrekende matchtypen rekening met de ATR-reikwijdte hierboven; de optie inschakelen bewijst geen ondersteuning voor betwiste X-Ops-richtingen.
Wireless: Logs van access points en SSID’s zijn niet beschikbaar in de lokale Log Viewer. Ze moeten gericht naar Sophos Fusion of Syslog worden gestuurd en daar worden gecontroleerd.
Content filtering en SSL/TLS: Het geselecteerde logtype vervangt de logging in de bijbehorende firewall- of inspectieregel niet.
Webproxy: Bij webverkeer op poort 80 of 443 kan het Firewall-log Allowed tonen terwijl Web Filter hetzelfde verzoek blokkeert. Correleer beide gebeurtenissen om de daadwerkelijk toegepaste beleidsbeslissing vast te stellen.

Indeling en parser controleren

Een parsertest mag niet alleen aantonen dat er willekeurige tekst binnenkomt. De belangrijkste waarden moeten als afzonderlijke velden doorzoekbaar zijn. Dit ingekorte, geanonimiseerde voorbeeld komt overeen met het Standard syslog protocol voor een firewallregelgebeurtenis:

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

De legacy-indeling gebruikt daarentegen onder andere device, date, time, timezone, device_id en priority. Velden zoals status, user_name, nat_rule_id of log_occurrence hangen daarnaast af van het logtype en de gebeurtenis. Ze mogen niet als verplicht worden beschouwd voor elke gebeurtenis in de standaardindeling. De volgende lijst is een use-caseafhankelijke controlelijst, geen universeel verplicht schema. Bepaal de verplichte velden afzonderlijk voor elk ingeschakeld logtype aan de hand van het schema voor de gebruikte versie en een representatieve echte gebeurtenis. Regel- en NAT-velden gelden alleen voor de overeenkomstige bevestigde gebeurtenistypen; beoordeel verbindings- en gebruikersvelden en log_occurrence alleen wanneer ze worden geleverd. Ontbrekende velden die niet van toepassing zijn op het gebeurtenistype mogen niet leiden tot het weggooien van geldige gebeurtenissen of tot classificatie als parserfout.

Afhankelijk van de use case zijn voor de acceptatie vooral de volgende velden belangrijk:

Identiteit: device_name, device_model, device_serial_id
Classificatie: log_id, log_type, log_component, log_subtype, severity
Beleid: fw_rule_id, fw_rule_name, nat_rule_id
Verbinding: src_ip, dst_ip, poorten, protocol en gebruiker
Tijd en frequentie: timestamp, tijdzone en log_occurrence

log_id bevat het logtype, de component, het subtype, de Severity en de Message ID. Daardoor zijn detectieregels stabieler dan zoekopdrachten in platte tekst. Welke velden een specifieke module levert, moet desondanks aan de hand van een echte gebeurtenis van dat logtype worden gecontroleerd.

De twaalf tekens hebben vaste posities: teken 1 en 2 vormen de Log Type ID, 3 en 4 de Component ID, 5 en 6 de Subtype ID, teken 7 de Priority ID en teken 8 tot en met 12 de Message ID. 010101600001 wordt dus gelezen als 01 / 01 / 01 / 6 / 00001. Een parser moet voorloopnullen en vaste veldbreedtes behouden; controleer daarnaast ook log_type, log_component, log_subtype en severity.

De Syslog-module Events is niet hetzelfde als configuration-audit.log. Waarden van vóór en na de wijziging zijn daar alleen beschikbaar voor ondersteunde sleutelobjecten, zoals firewallregels, interfaces en IP-hosts, niet voor elke configuratiewijziging. De reikwijdte en analyse worden behandeld in het artikel over Audit Trail-logs.

In het gedocumenteerde voorbeeld 010101600001 betekent de eerste 01 Security policy, de tweede 01 Firewall rule, de derde 01 Allowed, 6 Information en 00001 Firewall traffic allowed. ID’s met vaste posities en uitgegeven tekstvelden hebben verschillende functies; leid de tekstvelden niet zonder verificatie af uit een numerieke ID. Andere Message IDs vereisen een Syslog-referentiecatalogus passend bij de gebruikte SFOS-versie; deze uitsplitsing verklaart niet elk gebeurtenistype.

Meerdere firewalls en HA

In een omgeving met meerdere appliances moet elke gebeurtenis eenduidig aan een firewall, locatie, klant en HA-cluster kunnen worden gekoppeld. De hostnaam, het serienummer, het model en de Facility moeten daarom worden gedocumenteerd en in het SIEM filterbaar zijn. Vanaf SFOS 22.0 identificeert device_name de hostnaam van de firewall die het log heeft geproduceerd. Controleer na een upgrade of de parser dit veld verwerkt en niet uitsluitend device_serial_id of de Syslog-header als assetsleutel blijft gebruiken.

Na een HA-failover, herstelbewerking of hardwarevervanging moet worden gecontroleerd of gebeurtenissen nog aan de bestaande asset worden gekoppeld of als een nieuw of dubbel systeem verschijnen. Hetzelfde geldt na een wijziging van de hostnaam of de Syslog-indeling.

De integratie met echte gebeurtenissen testen

Een groene collectorstatus bewijst niet dat de juiste logs zijn geselecteerd of dat de parser werkt. Voor de acceptatie:

Documenteer een pilotfirewall en de uitgangssituatie: servernaam, doel, poort, TLS, Facility, Severity, Format en alle logtypen die in de kolom van de server zijn ingeschakeld.
Stuur aanvankelijk Firewall en Events naar het doel.
Genereer verkeer dat overeenkomt met een gelogde testregel met een gedefinieerde bron, bestemming en service.
Controleer in het SIEM het apparaat, de tijd, het logtype, de actie, de Rule ID, de bron en de bestemming.
Genereer een gedefinieerde drop en een VPN-aanmelding en -afmelding.
Test ten minste één beveiligingsgebeurtenis uit IPS, Content filtering of Active threat response, mits de module in productie wordt gebruikt.
Activeer daarna stapsgewijs meer logtypen en observeer het volume en het parserresultaat.

Bij het testen van regels helpt de handleiding voor Log Viewer, Policy Test en Packet Capture. Een negatieve test is ook belangrijk: blokkeer bewust een verwachte verbinding; deze moet als drop met de juiste regel verschijnen.

Bij HA- of migratieprojecten hoort een failover-, herstel- of hardwarevervangingstest bij de acceptatie. Het SOC moet daarna nog steeds kunnen herkennen welk apparaat en welke locatie de gebeurtenis heeft gegenereerd.

Een wijziging terugdraaien zonder gegevensonderbreking

Wijzig de indeling, minimale Severity en logselectie niet tegelijk. Als een van de vijf serverplaatsen vrij is, voegt u voor een parser- of collectormigratie een tweede doel toe en laat u beide eerst parallel werken. Zo kunt u ruwe gegevens, gevulde velden, tijdstempels en volume vergelijken zonder het werkende doel te wijzigen.

Schakel de logtypen in de kolom van het oude doel pas na acceptatie uit. Bewaar de serververmelding gedurende een afgesproken observatieperiode. Ontbreken er gebeurtenissen, mislukt de parsing of is het volume onverwacht, schakel daar dan precies de eerder gedocumenteerde logtypen weer in en draai de selectie bij het nieuwe doel terug. Is er geen serverplaats vrij, leg dan vóór elke afzonderlijke wijziging de huidige waarden vast en herstel ze volledig bij een fout; verwijder de vermelding niet en wijzig de parser niet tegelijk.

Verwijderen via de API is niet hetzelfde als het uitschakelen van de logkolom: De Delete-tabellen voor SFOS 22.0 en SFOS 23.0 vermelden alleen Name als niet verplicht, maar beschrijven dit als suppressiestatus en tonen geen doelselector. Deze tegenstrijdige tabel bewijst noch dat het doel veilig wordt geselecteerd wanneer de naam wordt weggelaten, noch dat het verwijderen van een collector gelijkwaardig is aan het deactiveren van zijn logtypen. Behoud de werkende collector tijdens de migratie. Voordat een vermelding via de API wordt verwijderd, moeten de eenduidige, goedgekeurde identiteit van de te verwijderen vermelding en de verwijderingssyntax zijn vastgesteld aan de hand van de API-help voor de specifieke build of met Sophos Support; raad geen selector.

Beheer, bewaring en uitval

Een Syslog-integratie heeft een eigenaar, een vastgelegde bewaartermijn en een reactie op alarmen nodig. Daarnaast moet vaststaan wie foutpositieven beoordeelt en detectieregels aanpast. Firewalllogs kunnen persoonsgegevens, interne adressen, gebruikersnamen, URL’s en VPN-activiteit bevatten. Toegangsrechten, verwijdertermijnen, tenantscheiding en SIEM-kosten moeten daarom vóór een brede uitrol worden vastgelegd.

Het beheer moet niet alleen aanvallen, maar ook ontbrekende gegevens herkennen:

Bewaak per firewall een verwacht minimaal activiteitsniveau.
Controleer belangrijke logtypen zoals Firewall, Events, IPS of Active threat response afzonderlijk op actualiteit.
Bewaak centrale parservelden op lege of plotseling hernoemde waarden.
Stel alarmen in voor het verlopen van certificaten en de status van de collector.
Genereer na firmware-, parser- en certificaatupdates opnieuw testgebeurtenissen.

Ook de bewaking zelf moet worden getest: als gegevens van een verwacht logtype of een firewall bewust uitblijven, moet het vastgelegde uitvalalarm afgaan.

Ruwe gegevens zonder geparste velden gelden eveneens als uitval. Een parserupdate kan het transport intact laten, terwijl dashboards en detectieregels geen treffers meer opleveren.

Syslog vervangt noch lokale servicelogs, noch een probleemoplossingsarchief voor support. Voor NetFlow-v5-records uit gericht gelogde firewallregels past NetFlow; voor interfacesamples en verkeerspatronen sFlow. Hardware- en interfacestatus kunnen daarnaast via SNMP worden bewaakt.

Fouten gericht isoleren

Er komen geen logs binnen: Controleer het doel, de poort, het transport, de routing en de externe firewall. Controleer daarna of het gewenste logtype in de Syslog-kolom is geactiveerd. Als de collector zich achter een VPN of managementnetwerk bevindt, moet ook rekening worden gehouden met de route, het SD-WAN-beleid en Source NAT.

Alleen bepaalde gebeurtenissen ontbreken: Controleer eerst de logging in de betreffende firewall- of inspectieregel en daarna het logtype onder Log settings. Controleer bij ATR ook het vereiste matchtype.

Stel eerst vast of de module en het verkeerspad worden ondersteund. Pas de ATR-reikwijdte hierboven toe: ontbrekende logs lossen het X-Ops-conflict niet op en betwiste richtingen zijn geen reden om zomaar extra matchtypen in te schakelen.

Ruwe logs komen binnen, maar velden ontbreken: Vergelijk de ingestelde indeling, de parserversie en de firmwareversie. Standaard- en legacy-velden mogen niet in hetzelfde parserprofiel worden verwacht.

TLS maakt geen verbinding: Controleer de TLS-poort en de serverservice en vervolgens de certificaatketen, FQDN, Common Name, SAN en LINCE-modus. De collector moet daarnaast de Sophos-CA Default.pem vertrouwen. Controleer bij certificaatwijzigingen beide truststores en het vernieuwingsproces.

Tijdstempels kloppen niet: Controleer NTP op de firewall en de collector, de tijdzone van het SIEM en de parsernormalisatie. Onjuiste tijden verhinderen een betrouwbare correlatie met endpoint-, server- en identiteitslogs.

Te veel logs of te veel ruis: Schakel niet zonder onderscheid alles uit. Evalueer eerst ongebruikte logtypen, regels die onnodig veel logs genereren, SIEM-use-cases en log_occurrence; beperk daarna de selectie gericht.