Stuur Sophos Firewall Syslog veilig naar SIEM

Met Syslog kan een Sophos Firewall gebeurtenissen naar een externe logserver, een SIEM of een beveiligingsplatform sturen. Dit is vooral belangrijk als logboeken langere tijd moeten worden bewaard, centraal moeten worden doorzocht, moeten worden gecorreleerd met andere systemen of moeten worden gebruikt voor audits en incidentrespons.

De lokale Logviewer is goed voor snelle analyse rechtstreeks op de firewall. Centrale Firewall-rapportage is handig als u Sophos Central als rapportageplatform gebruikt. Syslog is daarentegen de betere keuze als u over uw eigen SIEM, een SOC, een beheerd detectieproces of een fabrikantoverschrijdende logarchitectuur beschikt.

Welk houtkapartikel past?

Het inloggen op Sophos Firewall bestaat uit verschillende niveaus. Afhankelijk van de vraag is Syslog niet altijd de beste manier om te beginnen:

• Analyseer een enkele verbinding, Rule ID of web/IPS-beslissing live: Sophos Firewall Regel testen met Log Viewer, Beleidstester en Packet Capture
• Wijs lokale logbestanden en services toe: Sophos Firewall Probleemoplossing: Services en logboeken
• Maak een back-up van logboeken voor ondersteuning of externe analyse: Sophos Firewall Back-up van logboeken voor ondersteuning en analyse
• Configuratiewijzigingen en beheerdersacties bijhouden: Sophos Firewall Audittraillogboeken controleren
• Gebruik Sophos Central-gebaseerde rapporten over meerdere firewalls: Sophos Firewall Centrale rapportage activeren en bedienen
• Logboeken langdurig verzenden naar SIEM, SOC of logserver: Dit artikel
• Analyseer verkeersstromen in plaats van individuele firewallgebeurtenissen: Configureer sFlow-bewaking op Sophos Firewall
• Controleer de hardware- en interfacestatus via monitoring: Sophos Firewall SNMP-hardwarebewaking instellen

Dit houdt de evaluatie overzichtelijk: de Log Viewer beantwoordt de huidige pakket- of beleidscase, lokale logs helpen bij diepere modulediagnostiek, centrale rapportage is handig voor Sophos-evaluaties en Syslog biedt de externe lange termijn- en SIEM-laag.

Wanneer Syslog logisch is

Syslog is niet alleen de moeite waard voor grote omgevingen. Zelfs met een paar firewalls kan een centrale logserver helpen om gebeurtenissen langer en onafhankelijk van het apparaat te bewaren.

Typische gebruiksscenario’s:

• Centrale logopslag voor weken, maanden of jaren
• Correlatie met eindpunt-, server-, identiteits-, proxy-, cloud- of switchlogboeken
• SIEM-gebruiksscenario’s voor aanvallen, poortscans, VPN-aanmeldingen, WAF-gebeurtenissen of bedreigingsfeedhits
• externe evaluatie door SOC, MDR of interne beveiligingsteams
• Traceerbaarheid na firmware-updates, failover, herstel of hardwarevervanging
• Forensisch onderzoek wanneer lokale firewalllogboeken niet langer voldoende zijn

Lokale logboeken blijven belangrijk voor gevallen van acute probleemoplossing. Welk lokaal logbestand bij welke firewallmodule hoort, kunt u vinden in Sophos Firewall Probleemoplossing: Services en logboeken. Als u een back-up van logbestanden wilt maken voor ondersteuning of externe analyse, past Sophos Firewall Back-up maken van logbestanden voor ondersteuning en analyse.

Syslog, Central Reporting of lokale logs?

De drie routes beantwoorden verschillende vragen. In de praktijk worden er vaak meerdere parallel gebruikt.

• Log viewer: snelle liveanalyse op de firewall, maar geen centrale architectuur voor de lange termijn.
• Lokale logbestanden: detailanalyse via Advanced Shell of supportcase, maar afhankelijk van de toestand en opslag van de firewall.
• Central Firewall Reporting: Sophos Central-rapporten en eenvoudig overzicht over meerdere firewalls, maar gebonden aan Sophos Central, licentie en opslagkader.
• Syslog / SIEM: eigen bewaring, correlatie, detectie en audit. Daarvoor zijn parsers, beheer, monitoring en duidelijke use cases nodig.

Syslog vervangt de Log Viewer dus niet. Het vult hem aan. De Log Viewer toont snel welke regel of module heeft beslist. Syslog zorgt ervoor dat deze informatie later extern beschikbaar blijft.

Vereisten

Vóór de configuratie moeten deze punten worden verduidelijkt:

• Syslog-server of SIEM is bereikbaar.
• Doel-IP of FQDN is stabiel en gedocumenteerd.
• Haven en transport zijn vast, vaak UDP 514 of TLS op eigen poort.
• Firewall kan de Syslog-server routeren en bereiken.
• Er is een geschikte parser of op zijn minst een opslag van ruwe gegevens in het doelsysteem.
• NTP werkt op firewall en doelplatform.
• Bewaartermijn en vereisten voor gegevensbescherming zijn gedefinieerd.
• Het is duidelijk welke logtypes echt nodig zijn.

Voor externe of cloudgebaseerde SIEM-bestemmingen moet speciale aandacht worden besteed aan transportversleuteling, bron-IP, routing, DNS en certificaatverificatie. Sommige SIEM- of MDR-leveranciers verwachten opzettelijk niet-versleutelde Syslog naar een lokale collector of sensor die de gegevens vervolgens doorstuurt. Dan moet de niet-versleutelde route kort, intern gesegmenteerd en gedocumenteerd zijn.

Verduidelijk gegevensbescherming, opslag en verantwoordelijkheid

Syslog is niet alleen een technische omleiding. Firewalllogboeken kunnen interne IP-adressen, gebruikersnamen, doelsystemen, URL’s, categorieën, VPN-aanmeldingen, beheerdersgebeurtenissen en beveiligingshits bevatten. Daarom moet vóór de productieve verbinding duidelijk zijn wie deze gegevens mag zien en hoe lang deze worden bewaard.

Verduidelijk vóór de uitrol:

• Opslag: Hoe lang moeten operationele, audit- of incidentresponslogboeken beschikbaar blijven?
• Toegang: Welke mensen of teams kunnen onbewerkte logboeken, zoekopdrachten en dashboards zien?
• Gegevensbescherming: Bevatten logboeken persoonlijke informatie, gebruikers-ID’s, bron-IP-adressen of URL’s?
• Mogelijkheid voor meerdere clients: Zijn locaties, klanten, huurders of HA-clusters duidelijk gescheiden in de SIEM?
• Kosten: Worden logvolumes, EPS, opslag of zoekopdrachten gefactureerd door de SIEM-provider?
• Alarmering: Wie reageert op alarmen en binnen welk tijdsbestek?
• Verwijdering: Hoe worden oude logbestanden verwijderd nadat de bewaartermijn is verstreken?

Deze verantwoordelijkheid mag niet open worden gelaten, vooral niet bij MSP-, SOC- of MDR-modellen. Een SIEM zonder duidelijke eigenaar levert data op, maar geen betrouwbaar antwoord.

Plan de uitrol in fasen

Voor productieve firewalls is een kleine pilot beter dan alle logtypen onmiddellijk naar alle bestemmingen te sturen. Hierdoor kunnen parsers, veldnamen, ruis en kosten worden beheerst voordat de SIEM als betrouwbare bron wordt gepland.

Een verstandig proces:1. Eerst wordt een pilotfirewall geselecteerd. 2. Hostnaam, tijdbron, firmwareversie en logformaat zijn gedocumenteerd. 3. De Syslog-bestemming is geconfigureerd met beveiligd transport. 4. Het begint met een paar logtypen, bijvoorbeeld firewall, gebeurtenissen en VPN. 5. Gedefinieerde testgebeurtenissen worden gegenereerd en gecontroleerd in het doelsysteem. 6. Parser, velden, tijdstempel, tijdzone en device_name zijn gevalideerd. 7. Volume en ruis van het logboek worden gedurende een paar dagen waargenomen. 8. Vervolgens worden extra logtypen toegevoegd, zoals IPS, Web, WAF, Active Threat Response of System Health. 9. Pas na een succesvolle pilot wordt het uitgerold naar andere firewalls.

Als u meerdere firewalls heeft, moet u niet alleen controleren of er gegevens binnenkomen. Belangrijk is of elke gebeurtenis wordt toegewezen aan de juiste locatie, apparaat, HA-node, klant of huurder.

De pilot moet ten minste één normale operationele gebeurtenis, één beveiligingsgebeurtenis en één foutgebeurtenis bevatten. Verder lijkt het transport gezond, maar de latere belangrijke velden ontbreken alleen in geval van nood.

Syslog-server toevoegen

De configuratie vindt plaats in de Sophos Firewall-webinterface.

1. Open System services > Log settings.
2. Selecteer Toevoegen.
3. Wijs een unieke naam toe, bijvoorbeeld siem-primary of syslog-soc.
4. Voer IP-adres/domein van de Syslog-server in.
5. Stel Poort zo in dat deze overeenkomt met het doelsysteem.
6. Kies bewust voor Faciliteit.
7. Stel Ernstniveau in.
8. Selecteer Formaat.
9. Schakel eventueel Secure log transmission in als de bestemming TLS ondersteunt.
10. Opslaan.

Sophos Firewall kan meerdere externe Syslog-servers configureren. De huidige documentatie voorziet in maximaal vijf Syslog-servers. Toch moet je niet elk doel willekeurig met elkaar verbinden, maar het doel achter elk doel bepalen.

Als u meerdere doelen heeft, moet u bewust de logselectie voor elk doel scheiden. Een lokale logserver heeft mogelijk alle firewall- en VPN-logboeken nodig, terwijl een MDR-verzamelaar alleen beveiligingsrelevante logtypen verwacht. Als alle doelen blindelings dezelfde gegevens ontvangen, nemen de kosten, het privacyrisico en de parserruis toe.

Belangrijke instellingen

Faciliteit

Deze faciliteit helpt de Syslog-server logbronnen of categorieën te onderscheiden. In eenvoudige omgevingen is een standaardwaarde vaak voldoende. In grotere omgevingen kan het zinvol zijn om firewalls of locatiegroepen te scheiden met behulp van verschillende LOCAL0 tot LOCAL7-waarden.

Belangrijk is dat de SIEM-regels, parsers en documentatie dezelfde logica gebruiken. Als elke firewall een andere faciliteit gebruikt, wordt de evaluatie onnodig moeilijk.

Ernstniveau

De ernst bepaalt de ernst waarmee logboeken worden verzonden. Uit veiligheidsoverwegingen en voor het oplossen van problemen is een te hoge drempel gevaarlijk omdat belangrijke informatie of kennisgevingsgebeurtenissen gemist kunnen worden. In zeer luide omgevingen kan een te lage drempel echter onnodig veel ruis genereren.

Het is meestal zinvol om een ​​pilot te hebben met een bredere selectie aan logs, en vervolgens een bewuste reductie op basis van echte hits en SIEM-gebruiksscenario’s.

De drempel is een minimale ernst. Als bijvoorbeeld Error wordt gekozen, stuurt de firewall ook kritischere meldingen zoals Critical, Alert en Emergency, maar geen normale informatie-events. Voor veel SIEM-use-cases zijn juist Information- en Notice-events belangrijk, omdat VPN-logins, regelevents of systeemstatussen anders kunnen ontbreken.

formaat

Volgens de huidige documentatie biedt Sophos Firewall twee formaten:

• Standaard syslog-protocol
• Apparaat standaardformaat (verouderd)

Voor nieuwe integraties moet u eerst controleren welk formaat het doelsysteem of de bestaande parser verwacht. Als een SIEM al een Sophos firewall-parser heeft, heeft zijn verwachting voorrang. Een formaatwijziging na de go-live kan dashboards, zoekopdrachten en detectieregels verbreken.

Secure log transmission

Wanneer Secure log transmission actief is, worden logs gecodeerd naar de Syslog-server verzonden. Om dit te doen moet het doelsysteem TLS op de geconfigureerde poort accepteren, een geschikt servercertificaat afleveren en een certificaatketen gebruiken die de firewall vertrouwt. Voordat u live gaat, moet u niet alleen de firewall controleren, maar ook de certificaatnaam, vertrouwensketen, poort, parser en vernieuwingsproces van het Syslog-doel.

UDP kan technisch gezien voldoende zijn voor interne laboratoria. Niet-versleutelde Syslog via onveilige netwerken is echter geen goede basis voor productieve SIEM- of SOC-verbindingen, omdat loggegevens interne IP-adressen, gebruikers, bestemmingen, URL’s of beveiligingsgebeurtenissen kunnen bevatten.

Bij TLS is de naam van de Syslog-bestemming belangrijk. Zonder geactiveerde LINCE-compliancemodus controleert Sophos Firewall de Common Name van het certificaat tegenover het domein van de Syslog-server; in dit standaardgeval wordt de Subject Alternative Name niet als vervanging gebruikt. Met LINCE actief kan Common Name of Subject Alternative Name passen. Als er een IP-adres in de firewall is ingevoerd maar het certificaat alleen een DNS-naam bevat, of als een certificaat alleen via SAN past, kan de verbinding afhankelijk van de modus mislukken. Voor productieve TLS-Syslog-doelen zijn een stabiele FQDN, een passend servercertificaat en een gedocumenteerd vernieuwingsproces nodig.

Tegelijkertijd moet het doelsysteem de gekozen procedure echt begrijpen. Sommige SIEM-integraties vereisen een lokale collector en ondersteunen niet rechtstreeks de Secure log transmission-firewall. Dan is vaak de betere oplossing: Firewall stuurt intern naar de verzamelaar, de verzamelaar versleutelt verder naar de cloud of het SOC-platform. Deze architectuur moet in het operationele document worden opgenomen, anders wordt later ten onrechte aangenomen dat alle delen van de route gecodeerd zijn.

Selecteer logtypen

Na het toevoegen van de Syslog-server is het werk nog niet klaar. Onder System services > Log settings moet u opgeven welke logtypen naar deze bestemming worden verzonden.

Belangrijk: Een firewallregel maakt alleen betekenisvolle verkeerslogs als Log firewall traffic in de regel is geactiveerd. Voor SSL/TLS Inspection moet ook Log connections actief zijn in de passende inspectieregel. De logselectie onder Log settings bepaalt daarna of deze logs lokaal, naar Sophos Central of naar Syslog-servers worden verzonden.

Typische houtsoorten voor een SIEM:

• Firewall: toegestane en afgewezen verbindingen, overeenkomen van regels, DoS-gebeurtenissen
• IPS: Aanvallen gedetecteerd of geblokkeerd
• Web-/inhoudsfiltering: Webverkeer, categorieën, webbeleidsgebeurtenissen
• SSL/TLS-inspectie: TLS-inspectiebeslissingen en -fouten
• Beveiliging van webserver: WAF-evenementen voor gepubliceerde services
• Authenticatie / Gebeurtenissen: Beheerder-, gebruikers- en systeemgebeurtenissen
• VPN: Toegang op afstand en site-to-site VPN-gebeurtenissen
• Actieve dreigingsreactie: Hits van MDR Threat Feeds, NDR Essentials, Sophos X-Ops en Threat Feeds van derden
• Systeemstatus: CPU, geheugen, gebruikers, interfaces en partities

Als DoS of spoof-gebeurtenissen moeten worden geëvalueerd, moet ook de technische verharding zelf worden getest. Het proces vindt plaats in Sophos Firewall Controleer instellingen Spoof Protection en DoS.

Als Threat Feeds van derden, NDR en Active Threat Response of WAF worden gebruikt, moet de SIEM deze gebeurtenissen specifiek evalueren. Alleen het versturen van logs is niet voldoende. Het vereist duidelijke zoekopdrachten, alarmen, verantwoordelijkheden en afstemming op valse alarmen.

Parservelden bewust controleren

Sophos-Syslog-events bevatten afhankelijk van het logtype verschillende velden. Voor parsers en dashboards zijn vooral log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name en timestamps relevant.

log_id is meer dan een willekeurig nummer. De ID bestaat uit logtype, component, subtype, severity en Message ID. Dat helpt wanneer een SIEM niet alleen vrije tekst moet doorzoeken, maar stabiele detectieregels, dashboards of normalisaties moet bouwen.

Voor acceptatie moet men daarom niet alleen controleren of raw data aankomt. Beslissend is of de velden echt als afzonderlijke velden in het SIEM landen. Als fw_rule_id of nat_rule_id alleen in de ruwe tekst blijft staan, werken latere zoekopdrachten en alarmen vaak slechter dan verwacht.

Een geanonimiseerd firewall-event kan er in raw formaat bijvoorbeeld zo uitzien:

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

Het voorbeeld vervangt geen officiële veldreferentie. Het laat zien welke informatie bij de parser-test als afzonderlijke velden zichtbaar moet zijn.

Typische startset voor SIEM piloot

Voor een piloot is een kleine, weloverwogen startset beter dan volledige activering zonder evaluatie.

• Begin: Firewall, Evenementen, VPN. Controleer de ruisvloer, regelgebeurtenissen, beheerder en zichtbaarheid van VPN
• Beveiliging: IPS, Web, Webserverbescherming, Actieve reactie op bedreigingen. Valideer gebruiksscenario’s voor beveiliging en parservelden
• Operatie: Systeemgezondheid, DHCP, DNS, Authenticatie. Operationele en identiteitscontext toevoegen
• Fijnafstemming: extra modules indien nodig. alleen activeren als er sprake is van een zoek-, alarm- of auditdoel

Na elke fase moet worden gecontroleerd of de SIEM de velden correct herkent en of iemand daadwerkelijk gebruik maakt van de nieuwe evenementen. Niet-aangevinkte logtypen zijn geen toegevoegde waarde, maar alleen maar extra volume.

Belangrijke zichtbaarheidsvallen

In Syslog-projecten ontstaan er niet veel gaten in het transport, maar vooraf: de firewall genereert helemaal niet de verwachte gebeurtenis, het logtype wordt niet naar de Syslog-server verzonden of de SIEM interpreteert de velden verkeerd.

Registratie van regels en modules

Firewallregels en SSL/TLS-inspectieregels moeten zelf logboekregistratie genereren. Onder System services > Log settings kunt u kiezen of deze logs lokaal, in Sophos Central of naar de Syslog-server worden verzonden. Als een firewallregel geen Firewallverkeer loggen, kan de Syslog-server geen volledige geschiedenis van het firewallverkeer weergeven.

Voor webbeleidsgebeurtenissen is het ook relevant of de bijbehorende firewallregel verkeersregistratie genereert. Anders ziet u mogelijk minder web- of inhoudfiltergebeurtenissen in de SIEM dan verwacht.

Logboekonderdrukking

Sophos Firewall kan meerdere identieke opeenvolgende logvermeldingen onderdrukken. Dit bespaart geheugen en verwerking, maar kan verwarrend zijn in gebruiksscenario’s van de SIEM wanneer telwaarden, frequentie of burst-gedrag moeten worden geëvalueerd. De functie werkt op Log Viewer, Sophos Central en externe Syslog-servers.

Voordat u de SIEM productief uitrolt, moet u daarom het volgende bepalen:

• Welke firewallgebeurtenissen kunnen worden onderdrukt?
• Welke detectieregels heeft elke individuele verbinding nodig?
• Werkt de SIEM met getelde waarden of alleen met individuele gebeurtenissen?
• Hoe wordt gedocumenteerd dat logboekonderdrukking actief is?

Active Threat Response

Active Threat Response-logboeken zijn met name handig bij het gebruik van Threat Feeds, NDR Essentials of externe feeds. Sophos maakt onderscheid tussen verschillende matchtypes, bijvoorbeeld doelhits voor uitgaand verkeer en bronhits voor inkomend verkeer.

Belangrijk: Remote Source Match voor inkomend verkeer wordt niet automatisch geactiveerd. Als WAF- of DNAT-verkeer moet worden gemonitord op basis van bedreigingsfeeds, moet deze zichtbaarheid bewust worden gecontroleerd. Anders zullen de binnenkomende hits die een SOC vaak verwacht, ontbreken.

Draadloze logboeken

Draadloze logs zijn niet automatisch zichtbaar in de lokale Log Viewer. Toegangspunt- en SSID-logboeken moeten specifiek naar Sophos Central of Syslog worden verzonden en afzonderlijk in het doelsysteem worden onderzocht als draadloze gebeurtenissen relevant zijn voor de werking, ondersteuning of naleving.

Omgevingen met meerdere firewalls

In omgevingen met meerdere firewalls moet elke gebeurtenis uniek worden toegewezen aan een apparaat. Hostnaam, serienummer, model en andere velden zijn hiervoor relevant. Afhankelijk van het logtype kunnen velden zoals device_name, device_model en device_serial_id verschijnen in Syslog-gebeurtenissen. De SIEM moet deze velden niet alleen opslaan, maar ook bruikbaar maken voor filters, dashboards en alarmen.

Praktische aanbevelingen:

• Stel de hostnaam van de firewall netjes in.
• Overweeg locatie of rol in de hostnaam.
• Definieer een uniforme faciliteit of taggingstrategie.
• Controleer in de SIEM of gebeurtenissen kunnen worden gefilterd op firewall, locatie en cluster.
• Maak duidelijk onderscheid tussen HA-clusters en zelfstandige firewalls.

Deze toewijzing is vooral belangrijk na een hardwarevervanging of -herstel. Anders zien gebeurtenissen in de SIEM eruit als nieuwe of dubbele systemen.

Voor HA-clusters moet ook worden getest hoe gebeurtenissen verschijnen na een failover. Waar het om gaat is of operaties en SOC dezelfde locatie blijven herkennen of dat er plotseling een andere hostnaam, serienummer of nieuwe asset in de SIEM verschijnt.

Testconfiguratie

Na het opslaan moet de verbinding bewust worden getest. Een groen doelsysteem alleen bewijst niet dat de juiste logs met de juiste velden aankomen.

Testpunten:

1. Open System services > Log settings op de firewall.
2. Zorg ervoor dat de Syslog-server zichtbaar is.
3. Voor een veilig logtype activeert u Syslog als test.
4. Activeer een gedefinieerde actie, bijvoorbeeld een geregistreerde firewallregel of testtoegang.
5. Controleer in het doelsysteem of de gebeurtenis arriveert.
6. Controleer velden zoals tijd, hostnaam, device_name, bron, bestemming, Rule ID, actie en logtype.
7. Controleer de tijdstempel en tijdzone in de SIEM.
8. Controleer bij firewall-events of fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status en log_occurrence afzonderlijk doorzoekbaar zijn.

Voor het testen van regels is Test firewallregel met Log Viewer, Policy Test en Packet Capture nuttig. Als er helemaal geen gebeurtenissen plaatsvinden, is de oorzaak vaak niet het Syslog-transport, maar eerder een gedeactiveerde logging of een verkeerd logtype.

Betekenisvolle testgebeurtenissen

Een goede acceptatietest creëert niet zomaar een logboek, maar precies de gebeurtenissen waarnaar later wordt gezocht.

• Gelogde testregel staat een verbinding toe: Bron, Bestemming, Service, Actie, Rule ID en Firewall duidelijk zichtbaar
• Gedefinieerde dropregelhits: Drop-gebeurtenis verschijnt met de juiste richting en tijd
• VPN-gebruiker maakt verbinding en verbreekt: Gebruiker, tunneltype, tijd en firewall worden gedetecteerd
• Webbeleid of IPS-testgebeurtenis: Logtype, categorie of handtekening wordt correct opgelost door de parser
• ATR- of bedreigingsfeedtest, indien beschikbaar: Hit verschijnt in de verwachte gebruikssituatie en genereert geen vals alarm
• HA failover- of hersteltest indien gepland: Gebeurtenissen blijven traceerbaar toegewezen aan locatie, cluster en toestel. Voor productieve SIEM-regels moet u ook een negatief testresultaat documenteren: Wat gebeurt er als een verwachte gebeurtenis zich niet voordoet? Pas dan zal later blijken of een parser-, collector- of logtype stilletjes heeft gefaald.

Operaties en monitoring

Een Syslog-verbinding is geen eenmalige vangst. De werking moet regelmatig worden gecontroleerd en gecontroleerd.

Deze punten moeten in ieder geval worden gedocumenteerd:

• Wie is de eigenaar van het logplatform?
• Welke firewalls versturen logs?
• Welke logtypen worden verzonden?
• Welke bewaartermijn geldt?
• Welke parsers, dashboards en alarmen zijn eraan gekoppeld?
• Hoe herken je dat logs niet meer binnenkomen?
• Hoe worden formaatwijzigingen gecontroleerd na firmware-updates?
• Hoe worden certificaatverlopen, collectorupdates en parserwijzigingen gemonitord?
• Wie evalueert valse positieven en past de SIEM-regels aan?

Na firmware-updates moeten willekeurige controles worden uitgevoerd om te zien of belangrijke gebeurtenissen nog steeds correct worden geparseerd. Dit geldt vooral voor productieve SIEM-regels die afhankelijk zijn van specifieke veldnamen, logtypen of formaten.

Stille loguitval herkennen

Voor de operatie moet er een eenvoudige uitvalindicator bestaan:

• Per firewall: definieer het verwachte minimumaantal events per periode, bijvoorbeeld Firewall- of System-events.
• Per belangrijk logtype: controleer of Firewall, VPN, Web, IPS of Active threat response nog regelmatig events leveren.
• Per parser: bewaak of centrale velden zoals device_name, Source, Destination, Action en Rule ID gevuld blijven.
• Per collector: herken of een lokale collector geen data meer accepteert of niet meer doorstuurt.
• Na changes: gebruik firmware-update, parser-update, certificaatwissel, firewall-restore en HA-failover als aanleiding voor een nieuwe acceptatietest.

Een goede SIEM-operatie alarmeert dus niet alleen bij verdachte events, maar ook bij ontbrekende events. Als een productieve firewall plots geen logs meer levert, is dat zelf een operationeel event.

Problemen oplossen

Er komen geen logs binnen in de SIEM

Controleer eerst het IP-adres, de poort, de routering en de firewallregels tussen de Sophos Firewall en de Syslog-server. Controleer vervolgens of het juiste logtype is geactiveerd voor de Syslog-server onder System services > Log settings.

Als de Syslog-server toegankelijk is via een VPN-tunnel of een afzonderlijk beheernetwerk, controleer dan ook de route, het SD-WAN-beleid, de bron-NAT en de counter-firewall. Vanuit het perspectief van Sophos Firewall is Syslog normaal uitgaand verkeer; het moet daadwerkelijk de verzamelaar bereiken.

Alleen bepaalde evenementen ontbreken

Dan is de module- of rule logging vaak niet actief. Voor firewallregels moet Firewallverkeer loggen worden ingesteld. Voor web- of SSL/TLS-gebeurtenissen moet ook de juiste registratie van beleids- of inspectieregels worden gegenereerd.

Logboeken komen binnen, maar worden onjuist geparseerd

Controleer het formaat, de parserversie en de firmwareversie. Als u schakelt tussen Standaard syslog-protocol en Standaardformaat apparaat (legacy), moet de SIEM-parser hiermee overeenkomen.

TLS-Syslog maakt geen verbinding

Controleer FQDN, certificaat, Common Name, Subject Alternative Name, LINCE-modus, certificaatketen en poort. In de meeste omgevingen zonder LINCE moet de Common Name bij het geconfigureerde domein passen; een naam die alleen in de SAN past, is dan niet genoeg. Als de firewall een DNS-naam verwacht, maar de Syslog-server alleen is ingevoerd via een IP-adres, kan de certificaatcontrole ook mislukken. Controleer bovendien of het doelsysteem daadwerkelijk TLS op de geconfigureerde poort accepteert.

Als een SIEM-provider Secure log transmission niet rechtstreeks ondersteunt, moet men niet proberen de parser te redden met willekeurige formaten. Het is beter om een ​​ondersteunde lokale verzamelaar te hebben, een ander transportontwerp of een duidelijke beslissing over welke interne route onversleuteld blijft.

Tijdstempels zijn onjuist

Controleer NTP op de firewall, tijdzone in SIEM en parserlogica. Onjuiste tijden maken de correlatie met eindpunt-, server- of identiteitslogboeken onbetrouwbaar.

Te veel logs of te veel ruis

Deactiveer niet meteen alles. Controleer eerst welke logtypen echt nodig zijn, welke regels onnodig loggen en of logonderdrukking zinvol is. Verminder dan specifiek.

Controlelijst

• Syslog-server of SIEM is bereikbaar.
• Transport, poort en encryptie staan ​​vast.
• Voor TLS: FQDN, certificaat, vertrouwensketen en verlenging worden gecontroleerd.
• Formaat komt overeen met SIEM-parser.
• Facilitaire strategie is gedocumenteerd.
• Relevante logtypen worden geactiveerd onder System services > Log settings.
• Bij belangrijke firewallregels is Firewallverkeer loggen actief.
• SSL/TLS-inspectieregels genereren indien nodig hun eigen logbestanden.
• Logonderdrukking wordt bewust geëvalueerd en gedocumenteerd.
• Actieve dreigingsreactie-matchtypen komen overeen met de gebruiksscenario’s van de SIEM.
• Gegevensbescherming, toegang en bewaartermijn zijn verduidelijkt.
• Pilotfirewall, testgebeurtenissen en SIEM-parser zijn gevalideerd.
• Testgebeurtenissen arriveren in het doelsysteem.
• Velden zoals Hostnaam, device_name, Bron, Bestemming, Actie en Rule ID worden correct herkend.
• Belangrijke parservelden zoals log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity en status zijn afzonderlijk doorzoekbaar.
• HA, herstel- of hardwarevervangingsscenario is indien nodig opgenomen in het SIEM-kaartmodel.
• Tijdstempel en tijdzone zijn correct.
• Monitoring detecteert wanneer er geen logs meer binnenkomen.
• De parserfunctie wordt gecontroleerd na firmware-updates.

Veelgestelde vragen