Använd Sophos Firewall Health Check korrekt

Sophos Firewall Health Check är en integrerad brandväggskonfigurationskontroll. I Control Center visar det om viktiga inställningar motsvarar de rekommenderade säkerhets- och bästa praxisspecifikationerna. Detta är särskilt användbart för administratörer eftersom riskfyllda konfigurationer blir synliga innan de blir ett säkerhets- eller driftsproblem.

För det bredare hardening-sammanhanget passar hubben Sophos Firewall Hardening: best practices för säker konfiguration.

Sophos introducerade Health Check med Sophos Firewall v22. Enligt de officiella versionskommentarerna för SFOS 22.0 utvärderar funktionen dussintals konfigurationer mot CIS-benchmarks och annan bästa praxis. Det tidigare påståendet att SFOS 22.0 MR1 var den första versionen som uppdaterade CIS-kontexten stöds inte av denna källa.

Så används guiden

Health Check ger en lista men fattar inget beslut. Därför lägger guiden till en Avanet-bedömning:

• Hög prioritet: grundläggande säkerhets- eller driftkontroll; åtgärda eller motivera avvikelsen mycket väl.
• Kontextberoende: användbart, men inte för varje regel, trafikväg eller arkitektur.
• Täcks på annat sätt: säkerhetsmålet uppfylls redan av en likvärdig kontroll från en annan leverantör eller av en annan driftprocess. En dokumenterad override kan då vara korrekt.
• Valfritt: efterlevnadsfunktion eller extra Sophos-tjänst; röd status betyder inte automatiskt att brandväggen är osäker.

Denna klassificering ersätter inte en riskanalys. Den förhindrar att en låg Sophos-allvarlighetsgrad förminskar vikten av en säkerhetskopia eller att en valfri integration för snabbt blir ett inköpsprojekt.

Vad Health Check är avsedd för

Health Check är inte en klassisk systemstatus eller en hårdvarusensor. Den kontrollerar inte om ett nätaggregat är defekt eller om en SSD håller på att gå sönder. För detta behövs andra driftkontroller, till exempel kontroll av SSD-hälsan samt HA- och hårdvaruövervakning.

För återkommande kontroll av aktuell system-, tjänste-, säkerhets- och administratörsstatus används den dagliga administratörschecklistan för Sophos Firewall. Den kompletterar konfigurationens Health Check med Control Center, System graphs, rapporter och händelser.

Health Check är mer sannolikt att svara på dessa frågor:

• Är administrativ åtkomst för stor öppen?
• Är MFA aktiverat för kritiska inloggningar?
• Är brandväggsreglerna för öppna?
• Är säkerhetskopior, Hotfixes, loggning eller Sophos Fusion-funktioner korrekt förberedda?
• Avviker konfigurationen från rekommenderade säkerhetsstandarder?
• Finns det några fynd som bör klargöras innan en revision eller start?

Det är därför ett bra verktyg för att härda, granska och ändra kontroll. Den ersätter dock inte ren arkitektur, policydokumentation och manuell utvärdering.

⚠️ En grön Health Check betyder inte automatiskt att brandväggen är säkert planerad. Den visar om vissa testbara inställningar är korrekta. Nätverksdesign, affärslogik, undantag, användargrupper och operativa processer kräver fortfarande teknisk bedömning.

Skilj SFOS Health Check från Sophos Fusion Account Health Check

Två funktioner med liknande namn svarar på olika frågor. Den Firewall health check som beskrivs här körs på brandväggen från och med SFOS 22.0. Den kontrollerar kontinuerligt den lokala konfigurationen och finns under Monitor & analyze > Firewall health check eller via widgeten i Control center. Hjälpen för SFOS 22 anger inget separat licenskrav för Health Check. Enskilda funktioner som kontrolleras, till exempel NDR, MDR threat feeds eller DNS Protection, kan ändå kräva egna licenser och beroenden av Sophos Fusion.

Sophos Fusion Account Health Check (tidigare Sophos Central Account Health Check) är däremot en Sophos Fusion-tjänst för hela kunden under My Environment > Account Health Check. Enligt beräkningen av Sophos Fusion Health Check-poäng bedömer avsnittet Firewall för närvarande automatiska Sophos Fusion-säkerhetskopior. Endast licensierade brandväggar som hanteras av och är anslutna till Sophos Fusion påverkar poängen. Produktfiltret Network kräver dessutom MDR Plus och en hanterad brandvägg. Sophos Fusion-vyn är därför varken detaljvyn för de 31 lokala SFOS-kontrollerna eller en ersättning för den.

Åtgärderna skiljer sig också. Fix now i den lokala SFOS Health Check öppnar endast den berörda konfigurationssidan; administratören granskar och sparar ändringen. Fix automatically i Sophos Fusion Account Health Check kan däremot ändra inställningar. Enligt Sophos Fusion-proceduren för automatiska brandväggskopior ändrar Sophos Fusion som standard ett schema med Never till varje månad den första dagen och lägger till saknade brandväggar. Den som inte vill göra detta automatiskt konfigurerar Global Settings > Products and Services > Firewall > Schedule Backup manuellt. Säkerhetskopiorna körs klockan 08:00 i den lokala tidszonen för kontots region; tiden kan inte ändras.

När WebAdmin öppnas från Sophos Fusion avgör brandväggsbehörigheterna i Sophos Fusion vilka åtgärder som är möjliga: Full tillåter ändringar, Read-only endast visning och Help Desk övervakning, diagnostik, loggar och rapporter. Åtgärd kräver alltså en roll som får ändra den berörda inställningen. Åtkomst till diagnostik eller Health Check är inte i sig ett godkännande att göra en ändring.

Utvärdera poäng och status korrekt

Health Check är användbart, men ingen leverantörsneutral säkerhetsrevision. Det premierar även Sophos Fusion (tidigare Sophos Central), DNS Protection, NDR Essentials, MDR threat feeds och Synchronized Security. Ur Avanets perspektiv finns en tydlig del korsförsäljning: Noncompliant kan betyda en verklig lucka, som WebAdmin exponerat utan MFA, eller bara att en valfri Sophos-tjänst inte används trots att Microsoft Defender, annan EDR/NDR, SIEM eller DNS-filtrering redan täcker målet.

Avanets rekommendation: granska varje finding, men genomför inte alla utan bedömning. En röd punkt om WebAdmin, MFA, okrypterad autentisering, säkerhetskopior eller öppna regler kräver stor uppmärksamhet. En röd punkt om en olicensierad Sophos-tjänst är i första hand ett arkitektur- och produktbeslut, inte en automatiskt bevisad säkerhetslucka. Säkerhetsmålet, befintliga alternativ och driftsprocessen avgör om rätt åtgärd är att aktivera, täcka på annat sätt eller göra en motiverad override.

Varje rekommendation bör därför inte aktiveras enbart för att göra statusen grön. Ett exempel är Login disclaimer: ett inloggningsmeddelande kan krävas i revisions- eller efterlevnadsmiljöer. I många normala driftsmiljöer innebär det främst ett extra klick vid varje inloggning och ger praktiskt taget ingen teknisk säkerhetsvinst. När funktionen behövs förklarar Konfigurera inloggningsmeddelande och meddelandetexter på Sophos Firewall texthantering, förhandsvisning, verifiering och rollback. Om det bara höjer Health Check-poängen är mervärdet begränsat.

Fråga vilket konkret hot funktionen minskar, om en likvärdig kontroll redan finns, vilken licens och dataöverföring som krävs och vem som hanterar larm, undantag och falska positiva. Utan tydliga svar är en dokumenterad override ofta ärligare än en oanvänd funktion som bara aktiveras för poängen.

Behandla inte NDR Essentials och MDR som samma sak. NDR Essentials analyserar vald brandväggstrafik och skapar detekteringar. Sophos MDR betyder Managed Detection and Response och är en extra betaltjänst med analytiker och incidentprocesser. MDR threat feeds är bara meningsfulla när tjänsten faktiskt är licensierad och integrerad i driften. Ett NDR-fynd betyder därför inte automatiskt att MDR måste köpas.

Som en tumregel:

• Internetexponerad hanteringsåtkomst, MFA, Hotfixes, säkerhetskopior, lösenordsregler och IPS är vanligtvis äkta säkerhet eller operativa grunder. Dessa punkter bör tas på största allvar.
• Loggning, rapportering, aviseringar och NTP är viktiga för verksamheten och spårbarheten. Den specifika vägen beror dock på driftsmodellen.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Fusion och Synchronized Security är möjliga lösningar, inte universella krav. En effektiv befintlig kontroll är viktigare än Sophos-logotypen.
• Inloggningsfriskrivning är vanligtvis mer en efterlevnads-/meddelandefunktion än en teknisk skyddsåtgärd. Du bör bara aktivera det om det verkligen krävs eller önskas.

Snabbt beslut: vad bör faktiskt implementeras?

När Health Check öppnas för första gången kan fynden delas in i fyra arbetsgrupper:

• Kontrollera omedelbart och åtgärda normalt: 8, 9, 11, 13-20, 22, 25, 28 och 31. Det omfattar hotfixstatus, inloggningsskydd, administratörslösenord, MFA, krypterad autentisering, SSH, WAN-exponering, pattern updates, IPS, breda regler och korrekt tid.
• Mycket viktiga även om Sophos klassificerar dem som Low eller Medium: 16 och 21. Säkerhetskopior kräver en testad återställning. Larm kräver en fungerande väg via e-post, övervakning, Sophos Fusion eller SIEM.
• Avgör per trafikväg och arkitektur: 3, 5, 10 och 23-27. X-Ops, Heartbeat, användarlösenordsregler, Web Policy, Zero-Day Protection, Application Control och TLS Inspection är inte lika användbara i varje regel.
• Aktivera endast med rätt Sophos-ekosystem eller ett medvetet beslut om molntjänst: 1, 2, 4, 6, 12, 29 och 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection och Sophos Fusion-funktioner är inga universella minimikrav. Punkt 7, Login disclaimer, är främst ett efterlevnadsbeslut.

Denna indelning är medvetet tydligare än Sophos allvarlighetsgrad. Den bedömer vad som först minskar risken i den verkliga miljön, inte vad Sophos kan sälja eller tekniskt integrera.

Öppna Health Check

Status för hälsokontroll visas i Kontrollcenter. Den detaljerade vyn finns också i huvudmenyn:

Monitor & analyze > Firewall health check

Där visas antalet kontrollerade konfigurationer, antalet punkter som uppfyller respektive policy och antalet punkter som inte gör det. Sophos visar punkter som inte uppfyller policyn efter allvarlighetsgrad. Data uppdateras när en övervakad konfiguration ändras. Detta gör Health Check även lämplig för direkt uppföljning efter ändringar.

För granskningen bör du inte bara notera den övergripande statusen. Vad som är viktigare är de specifika fynden, riskkontexten och den planerade åtgärden. Ett enda kritiskt fynd om WANs tillgänglighet för WebAdmin är viktigare i drift än flera lågnivåfynd utan internetexponering.

Förstå status, svårighetsgrad och åsidosättande

Den detaljerade vyn visar för varje kontroll om konfigurationen uppfyller policyn, inte uppfyller policyn eller har en manuellt åsidosatt policystatus. Dessa tre tillstånd är viktigare för driften än det rena procentvärdet.

• Uppfyller policyn: Den kontrollerade konfigurationen uppfyller respektive policy. Efter större ändringar bör den ändå valideras tekniskt.
• Uppfyller inte policyn: Den kontrollerade konfigurationen uppfyller inte policyn. Risk, exponering och genomförbarhet måste bedömas.
• Manuell åsidosättning av policystatus: Konfigurationen uppfyller inte policyn, men har manuellt markerats som att den gör det. Denna status bör endast användas med motivering, ägare och datum för ny granskning.

Öppna åtgärdsmenyn via de tre punkterna i kolumnen Action för det aktuella fyndet. Fix now öppnar motsvarande konfigurationssida, där ändringen granskas och sparas manuellt. Override status markerar manuellt ett fynd som inte uppfyller policyn som Complies, utan att ändra konfigurationen. Undo override visas endast för en policy vars status redan har åsidosatts och återställer den till Doesn't comply; åtgärden återställer inte en konfigurationsändring. Detta är praktiskt, men ersätter inte en bedömning: Health Check vet inte automatiskt om en likvärdig kontroll faktiskt tillämpas någon annanstans.

Allvarlighetsgraden hjälper till med sorteringen, men ersätter inte en specialistbedömning. Det är en statisk Sophos-värdering utan kännedom om exponering eller kompenserande kontroller. Ett Low-fynd för saknade säkerhetskopior kan vara mer akut än ett Medium-fynd för en oanvänd Sophos-tjänst.

Om ett fynd verkar orimligt bör även firmwareversionen och kända fel kontrolleras. De officiella versionskommentarerna listar för SFOS 22.0 GA Build 411 NC-165825 för ett felaktigt Doesn't comply-resultat för NDR Essentials på virtuella brandväggar, NC-169472 för ett felaktigt fynd om brandväggsregler och NC-167645 för sortering som inte kvarstod efter Override status. Dessa ID:n bekräftar endast de beskrivna felen och är ingen allmän förklaring till senare resultat. Om beteendet återkommer på en aktuell build ska policy, faktisk konfiguration och build först dokumenteras och Sophos Support därefter kontaktas, i stället för att en riskfylld inställning ändras bara för att få grön status.

Sök- och sorteringsfunktionerna i hälsokontrolltabellen hjälper till att gruppera resultat efter policy, modul, standard eller svårighetsgrad. För större brandväggar är detta mer praktiskt än att bara titta på instrumentpanelen.

Individuell bedömning av Health Check-kontrollerna

Listan bygger på de 31 kontrollerna i den engelska Health Check-vy som användes för denna granskning. Sophos kan ändra antal, namn, standard eller allvarlighetsgrad med en firmwareuppdatering. Om den lokala brandväggen visar ytterligare eller annorlunda namngivna fynd är den vyn avgörande. Statusen anges inte eftersom den varierar mellan brandväggar. Det viktiga är att förstå och bedöma varje kontroll korrekt.

Active Threat Response och avancerad säkerhet

• 1. Synchronized Application Control bör vara aktiverad. Standard: Rekommenderas, Allvarlighet: Medium. Funktionen identifierar applikationer mer exakt via Sophos Endpoint och kräver Security Heartbeat; vid första användningen måste den även aktiveras i Sophos Fusion. Avanet-bedömning: valfritt. Aktivera endast med kompatibla Sophos-endpoints och när upptäckta applikationer senare ska klassificeras och användas via Application Filter. Med Microsoft Defender eller en annan endpointprodukt är en motiverad override mer användbar än en aktivering utan effekt.
• 2. NDR Essentials bör aktiveras och övervaka minst ett gränssnitt. Standard: Rekommenderas, Allvarlighet: Medium. Brandväggen analyserar vald trafik via Sophos NDR-molntjänst, upptäcker IoC:er och loggar dem men blockerar dem inte automatiskt. Vissa gränssnitt i LAN-, DMZ- och Custom-zoner stöds; WAN, Wi-Fi och flera gränssnittstyper, som RED och XFRM, är undantagna. Active-Active HA stöds inte. Active Threat Response-loggar måste också vara aktiverade och beroende på IoC-typ måste firewall-, DNS-, IPS- eller decryptionkontroller vara verksamma. Avanet-bedömning: kontextberoende eller valfritt. Aktivera endast när licens, molnanalys, dataskydd, lämpliga gränssnitt och larmansvar är klargjorda. Ersätt inte ett befintligt NDR endast för att göra Health Check grönt.
• 3. Sophos X-Ops bör vara aktiverat, åtgärd Log and drop. Standard: CIS, Allvarlighet: Hög. Detta är relevant för säkerheten om Threat Feeds används aktivt. Falska positiva och loggning måste kontrolleras.
• 4. MDR threat feeds bör aktiveras, åtgärd Log and drop. Standard: Rekommenderas, Allvarlighet: Hög. Det kräver Sophos MDR, registrering i Sophos Fusion och lämpliga licenser. Avanet-bedömning: valfritt. Den länkade guiden beskriver pilot, Audit ID, Task Queue och incidentverifiering. Utan MDR-avtal är detta ingen konfigurationslucka utan en produkt- och tjänsterekommendation.
• 5. Synchronized Security Heartbeat ska användas i en brandväggsregel. Standard: CIS, Allvarlighet: Medium. Avanet-bedömning: kontextberoende. Funktionen är mycket användbar med Sophos Endpoint, men passar inte med Microsoft Defender eller annan EDR. Ett pilottest är nödvändigt: enheter som aldrig har skickat heartbeat kan beroende på regeln ändå få åtkomst. Alternativen Block clients with no heartbeat och Block request to destination with no heartbeat framtvingar det avsedda beteendet för sådana enheter.
• 6. Security Heartbeat bör vara aktiverat. Standard: CIS, Allvarlighet: Hög. Detta är viktigt i Sophos endpoint-miljöer. Annars måste ändpunktsdesignen förtydligas först.
• 12. DNS Protection ska vara konfigurerad och aktiv. Standard: Rekommenderas, Allvarlighet: Medium. Statusen Active kräver rätt licens, DNS Protection-resolvers på brandväggen och brandväggens publika IP-adress som Location i Sophos Fusion. Avanet-bedömning: valfritt. Aktivera endast om tjänsten medvetet används som DNS-säkerhetslager och loggarna granskas. Andra DNS-filter kan täcka samma mål utan att Sophos Health Check markerar dem som compliant.

Admin, autentisering och Device Access

• 7. Login disclaimer bör aktiveras. Standard: CIS, Allvarlighet: Medium. Avanet-bedömning: valfritt eller compliancekrav. Ett juridiskt avstämt meddelande kan krävas i reglerade miljöer. Det skyddar inte brandväggen tekniskt och bör inte aktiveras enbart för en bättre poäng.
• 8. Hotfix-inställningen bör vara aktiverad. Standard: CIS, Allvarlighet: Hög. Avanet-bedömning: hög prioritet. I aktuella SFOS 22-versioner visas inget separat Hotfix-block under Backup & firmware > Firmware. Sophos installerar hotfixar automatiskt som standard; status kan kontrolleras med system hotfix show i Device Console. En saknad kryssruta i gränssnittet är inget fynd.
• 9. Inaktiva sessioner bör avslutas och inloggningar blockeras efter misslyckade försök. Standard: CIS, Allvarlighet: Hög. Detta är tydlig inloggningshärdning och är särskilt viktigt för exponerade portaler och administratörsåtkomst.
• 10. Användarlösenordskomplexitet bör konfigureras. Standard: CIS, Allvarlighet: Hög. Detta är särskilt relevant för lokala användare och portaler. Om en extern IdP används bör dess lösenord och MFA policy också kontrolleras.
• 11. Lösenordskomplexitet för administratörer bör konfigureras. Standard: CIS, Allvarlighet: Hög. Detta är grundläggande härdning. Ännu viktigare är individuella administratörer, MFA och begränsad åtkomst.
• 13. MFA för Remote Access VPN inloggningar bör vara aktiva. Standard: CIS, Allvarlighet: Hög. Mycket viktigt för SSL VPN och IPsec fjärråtkomst. Lanseringen kräver reservadmin och testanvändare.
• 14. MFA för WebAdmin Console och VPN Portal bör vara aktiva. Standard: CIS, Allvarlighet: Hög. Detta är särskilt viktigt när portaler kan nås från mindre hårt kontrollerade nätverk.
• 15. Anslutningar till autentiseringsservrar bör krypteras. Standard: CIS, Allvarlighet: Medium. Okrypterad autentisering bör undvikas för AD/LDAP/RADIUS-anslutningar.
• 17. Autentisering med offentlig nyckel för SSH bör vara aktiverad. Standard: Rekommenderas, Allvarlighet: Hög. Dessutom bör SSH endast tillåtas från pålitliga nätverk.
• 18. User Portal ska inte vara tillgänglig från zonen WAN. Standard: Rekommenderas, Allvarlighet: Hög. Om WAN åtkomst är nödvändig bör den vara kraftigt begränsad och skyddad med MFA.
• 19. WebAdmin Konsol bör inte vara tillgänglig från zonen WAN. Standard: CIS, Allvarlighet: Hög. Detta är en av de viktigaste punkterna. WebAdmin bör aldrig öppnas brett på Internet.
• 20. MFA för standardadmin bör konfigureras. Standard: CIS, Allvarlighet: Hög. Dessutom krävs en ren administratörsprocess med personliga administratörskonton.

Backup, uppdateringar, regler och inspektion

• 16. Säkerhetskopiering bör schemaläggas på brandväggen eller i Sophos Fusion. Standard: CIS, Allvarlighet: Låg. Svårighetsgraden verkar låg, men i en nödsituation är punkten extremt viktig. Kryptera säkerhetskopiorna, förvara dem utanför brandväggen och testa återställningsprocessen med dokumenterat resultat.
• 21. E-postmeddelanden bör konfigureras för system- och säkerhetshändelser. Standard: CIS, Allvarlighet: Låg. Sophos Firewall kan skicka meddelanden via e-post och SNMP; önskade händelser väljs under System services > Notification list. Avanet-bedömning: kontextberoende. En tillförlitlig och testad larmväg är avgörande. Om Syslog, SIEM, övervakning eller Central Alerts drivs tillförlitligt är e-post inte obligatoriskt. En konfigurerad SMTP-server utan valda händelser och leveranstest är ännu ingen larmprocess.
• 22. Automatiska pattern updates bör vara aktiverade. Standard: CIS, Allvarlighet: Hög. Avanet-bedömning: hög prioritet. Utan aktuella patterns tappar flera skyddsfunktioner effekt. Flödet för att konfigurera och kontrollera mönsteruppdateringar visar automatiken, statusarna och den separata installationen av APX- och RED-firmware. I Air Gap-miljöer behövs dessutom en dokumenterad manuell process för patterns och licenser.
• 23. En webbpolicy bör väljas i en brandväggsregel. Standard: Rekommenderas, Allvarlighet: Medium. Detta är vettigt för användarens webbtrafik, men bör inte blint appliceras på server-till-server- eller specialtrafik.
• 24. Zero-day protection bör väljas i en brandväggsregel. Standard: CIS, Allvarlighet: Hög. Funktionen passar lämpliga webb- och nedladdningsvägar. Licens, prestanda och falska positiva resultat måste beaktas.
• 25. IPS ska vara aktiverat och en IPS-policy ska väljas i en brandväggsregel. Standard: CIS, Allvarlighet: Hög. IPS är en viktig skyddspunkt, men måste väljas och loggas på lämpligt sätt för varje trafikväg.
• 26. En Application Control-policy bör väljas i en brandväggsregel. Standard: CIS, Allvarlighet: Medium. Detta är lämpligt för klienters internetregler. Kritisk eller okänd trafik bör först observeras i loggläge innan den blockeras.
• 27. En SSL/TLS Inspection-regel bör använda åtgärd Decrypt. Standard: CIS, Allvarlighet: Hög. TLS Inspection ska inte aktiveras blint: CA-distribution, integritetsskydd, hänsyn till certificate pinning, undantag, pilotfas samt support- och felsökningsprocesser är förutsättningar.
• 28. En Allow-regel bör inte använda Any överallt i nätverks- och servicefälten. Standard: CIS, Allvarlighet: Medium. Avanet-bedömning: hög prioritet. Begränsa breda regler till källa, mål och tjänst med hjälp av verkliga loggdata. Ett nödvändigt Any kan behållas, men ska motiveras, loggas och granskas regelbundet.

Sophos Fusion och tid

• 29. Sophos Central Reporting bör vara aktiverat. Standard: Rekommenderas, Allvarlighet: Medium. Det är användbart för central och långsiktig rapportering, men inte nödvändigt om Syslog/SIEM drivs korrekt.
• 30. Sophos Central Management bör registreras och aktiveras. Standard: Rekommenderas, Allvarlighet: Medium. Detta är praktiskt för central administration, säkerhetskopiering och rapportering. Inte alla miljöer vill ha eller behöver molnhantering.
• 31. En NTP-server bör konfigureras. Standard: CIS, Allvarlighet: Låg. Utan korrekt tid lider loggar, certifikat, autentisering och felsökning.

Prioritera och implementera resultat

Alla fynd har inte samma betydelse i alla miljöer. Vid en bra granskning sorteras därför fynden inte bara efter teknisk allvarlighetsgrad, utan även efter exponering och driftsrisk.

Den här ordningen har visat sig fungera väl:

1. Kontrollera Internet-exponerad hantering och portalåtkomst.
2. Kontrollera MFA och inloggningssäkerhet för administratörer, VPN portal, User Portal och fjärråtkomst.
3. Rensa upp brandväggsregler med källor, mål eller tjänster som är för breda.
4. Kontrollera loggning, säkerhetskopior och Hotfixes.
5. Kontrollera skyddsfunktioner per regel, till exempel IPS, webbpolicy, Application Control, TLS Inspection eller Zero-Day Protection.
6. Sophos Fusion-, Reporting- eller NDR-fynd utvärderas utifrån om funktionen faktiskt används och drivs i miljön.

Ordningen är pragmatisk: För det första de saker som är direkt synliga på Internet eller tillåter åtkomst till brandväggen. Sedan genomgång och städning av brandväggsregler samt skyddsfunktioner. Sedan drifts- och ekosystemämnen.

Genomför och återställ ändringar säkert

Dokumentera SFOS-build, fynd, ursprungligt värde och berörd trafikväg före den första korrigeringen. Ändringar av hanteringsåtkomst, autentisering, regler eller inspektion kräver dessutom en aktuell säkerhetskopia, en testad alternativ administratörsväg och en tydlig återställningsplan. Fix now är bara en navigeringslänk och inget godkännande att använda den föreslagna inställningen utan egen granskning.

Genomför ändringar var för sig eller i små, logiskt sammanhängande grupper. Kontrollera sedan både Health Check-statusen och den berörda funktionen: tillåten och nekad administratörsåtkomst, testinloggning med MFA, regelträffar i Log Viewer eller ett applikationstest efter en inspektionsändring. Om fyndet kvarstår ska du först bekräfta att rätt policy och objekt ändrades. Hjälpen anger ingen fast uppdateringstid utan endast att data uppdateras när en övervakad konfiguration ändras.

Om en bieffekt uppstår använder du ändringsärendet för att återställa den specifika inställningen till det dokumenterade ursprungsvärdet och validerar igen. En fullständig återställning är sista utvägen och måste passa plattformen och firmwareversionen. Override status ändrar inte konfigurationen och Undo override rullar inte tillbaka en korrigering; den återställer bara policystatusen till Doesn't comply.

Typiska fynd och lämpliga åtgärder

WebAdmin, User Portal eller VPN Portal är tillgänglig från för många nätverk

Om administrativa eller användarvända portaler är tillgängliga från för många zoner ökar risken för skanningar, brute force-försök och automatiserade inloggningsförsök med stulna inloggningsuppgifter (credential stuffing). Den viktigaste artikeln om detta är Sophos Firewall Säkra åtkomst: Konfigurera Device Access korrekt.

För produktiva miljöer bör du kontrollera:

• Är WebAdmin från WAN-zonen verkligen nödvändig?
• Finns det en Local Service ACL Exception Rule för management-IP-adressen eller administrationsnätet?
• Är SSH endast tillåten från betrodda nätverk?
• Är portalerna User Portal och VPN endast tillgängliga där de behövs?

MFA saknas eller är inte konsekvent aktiverad

MFA tillhör åtminstone administrativ åtkomst och fjärråtkomst. Om Health Check visar MFA resultat, bör du inte blint byta över för alla användare samtidigt. En kontrollerad utrullning med testanvändare, reservadmin och en ren tokenprocess är bättre.

De praktiska instruktionerna finns i MFA för Sophos Firewall WebAdmin, VPN Portal och aktivera fjärråtkomst.

Brandväggsreglerna är för öppna

Mycket breda regler med Any för källa, destination eller tjänst har ofta utvecklats historiskt. Inte varje bred regel är automatiskt fel, men var och en bör motiveras.

Dessa frågor är användbara för städningen:

• Vilken zon får egentligen komma åt vilken zon?
• Kan målnätverk eller -tjänster begränsas?
• Är loggning aktiverad så att regelträffarna syns?
• Finns det gamla testregler eller tillfälliga undantag?
• Kan regeln delas upp i flera mer begripliga regler?

Grunderna finns i Sophos Firewall regler och konfigurera dem korrekt. Om det är oklart vilken regel som gäller hjälper Testa brandväggsregel med Log Viewer, Policy Test och Packet Capture till.

Säkerhetskopieringar, Hotfixes och uppdateringsprocessen saknas

En Health Check kan indikera saknade säkerhetskopior eller uppdateringar/snabbkorrigeringsämnen. Dessa punkter är mindre spektakulära än portalexponering, men är avgörande i en nödsituation.

Innan du gör större ändringar bör du skapa en säkerhetskopia och veta hur en återställning fungerar. Processen beskrivs i Sophos Firewall Skapa eller återställ säkerhetskopia. För firmware-ämnen, se Sophos Firewall Firmware Update - Preparation and Best Practices.

Loggning och rapportering är ofullständiga

Om loggar saknas är operationen blind. Health Check kan ge vägledning om loggning eller rapporteringsämnen, men det faktiska beslutet beror på driftsmodellen.

För lokal analys är Log Viewer, serviceloggar och Packet Capture relevanta. För längre lagring krävs Central Firewall Reporting eller Syslog/SIEM. Om du inte vill undersöka enskilda logghändelser, utan snarare trafikflöden, bandbreddstoppar eller iögonfallande kommunikationsrelationer, är sFlow Monitoring också lämpligt. De lokala grunderna finns i Sophos Firewall Felsökning: tjänster och loggar.

Skyddsfunktioner är inte aktiva i regler

Ett vanligt problem är regler utan IPS, webbpolicy, Application Control, TLS Inspection eller Zero-Day Protection. Här ska man inte aktivera allt över hela linjen, utan hellre förstå trafikvägen.

Exempel:

• Användarwebbtrafik behöver andra kontroller än server-till-server-trafik.
• TLS Inspection måste införas på ett planerat sätt eftersom det kan störa applikationer.
• IPS och Application Control behöver loggning och en granskningsrutin.
• NDR eller hot feed-funktioner hjälper bara om fynden utvärderas senare.

För TLS Inspection passar Sophos Firewall infoga TLS Inspection korrekt. För Threat Feeds passar Sophos Firewall Threat Feeds.

Dokumentera granskningen och följ upp resultatet

Sophos Firewall låter dig åsidosätta statusen för individuella tester manuellt. Detta kan vara användbart om en rekommendation medvetet inte implementeras i din egen miljö.

Åsidosättanden ska inte ses som ett sätt att städa bort fynd. De är bara motiverade om kravet medvetet uppfylls på annat sätt eller om det finns en effektiv, likvärdig kompenserande kontroll. Ett dokumenterat exempel gäller policyn MFA should be configured for the default admin: om en miljö använder Microsoft Entra ID SSO med MFA som obligatorisk inloggningskontroll kan detta fynd, beroende på utformningen, åsidosättas med en teknisk motivering – men bara om den aktuella inloggningen eller det berörda kontot faktiskt har ett likvärdigt skydd. SSO med MFA för personliga administratörskonton bevisar inte i sig att standardadministratörskontot har ett likvärdigt skydd. Lokal reservåtkomst och nödåtkomst måste fortfarande skyddas och kontrolleras separat. Detta är inget generellt tillstånd att åsidosätta alla lokala MFA-fynd; även andra likvärdiga kontroller kan motivera ett undantag. Utan en sådan motivering kvarstår risken, även om Health Check-visningen ser bättre ut.

Om en punkt åsidosätts ska den dokumenteras:

• Varför är rekommendationen inte lämplig?
• Vem godkände beslutet?
• Är undantaget permanent eller endast tillfälligt?
• När ska det granskas på nytt?
• Finns det någon kompensationsåtgärd?

⚠️ En åsidosättning är inte en fix. Det är ett medvetet accepterande av risk eller ett dokumenterat undantag. Utan motivering gör detta Health Check mindre värdefull.

Dokumentera resultatet tydligt

En hälsokontroll ska ge ett begripligt resultat. Annars kommer du kort att se en instrumentpanel, men senare kommer du inte längre att veta vilket beslut som fattades och vilka punkter som fortfarande är öppna.

För små miljöer räcker ofta en kort uppföljningslista med följande fält:

• Datum: När testades Health Check?
• Firmware: Vilken SFOS-version utvärderades på?
• Fynd: Vilken artikel som inte uppfyller kraven rapporterades?
• Risk: Varför är punkten relevant eller mindre relevant i den här miljön?
• Åtgärd: Vad är förändrat, testat eller medvetet accepterat?
• Ansvarig: Vem kommer att klargöra saken professionellt eller tekniskt?
• Datum: När ska åtgärden vara klar eller omvärderad?
• Bevis: Skärmdump, ärende, ändrings-ID (Change-ID) eller anteckning i revisionsloggen.

För produktiva brandväggar bör bevis inte bara bestå av en skärmdump. Om en konfiguration har ändrats hör ändringssedeln, revisionsspår, påverkad brandväggsregel och resultatet av uppföljningskontrollen ihop. För ändringar av regler, gränssnitt, värdar och tjänster är Sophos Firewall Kontrollera granskningsloggar särskilt användbar.

Kontrollera igen för ändringar

Efter en fix bör du öppna Health Check igen och kontrollera om upptäckten verkligen har försvunnit. Dessutom krävs ett tekniskt funktionstest eftersom en grön status ensam inte bevisar att produktiv trafik fortsätter att fungera korrekt.

Exempel:

• Efter att ha ändrat Enhetsåtkomst kontrollerar du om administratörsåtkomsten från det avsedda hanteringsnätverket fortfarande fungerar och inte längre är tillgänglig från oönskade nätverk.
• Efter MFA ändringar, logga in med en testanvändare och kontrollera reservadministratören separat.
• Efter regeländringar, testa Log Viewer, Policy Test och berörda applikationer.
• Efter ändringar i konfigurationen för loggning eller rapportering, kontrollera att nya händelser faktiskt är synliga lokalt, i Sophos Fusion eller i Syslog.
• Ställ in en påminnelse om ny granskning efter en åsidosättning så att undantaget inte glöms bort permanent.

Om flera fynd bearbetas samtidigt bör ändringarna delas upp i små block. Annars, i händelse av ett senare problem, kommer det att vara oklart om Device Access, MFA, brandväggsregler, TLS Inspection eller annan förändring var orsaken.

Använd Health Check som en driftprocess

Health Check är starkast när den körs regelbundet och efter viktiga ändringar.

Användbara tider:

• efter den första konfigurationen eller en start,
• före och efter större regeländringar,
• före firmwareuppgraderingar,
• efter återställning eller byte av maskinvara,
• efter migrationer eller större arkitektoniska förändringar,
• före revisioner,
• kvartalsvis som en säkerhetsgranskning.

Revisionsspåret bör också användas för själva förändringar. Artikeln Sophos Firewall Check Audit Trail Logs förklarar hur man utvärderar configuration-audit.log och spårar konfigurationsändringar.

Praktisk granskningsprocess

En pragmatisk hälsokontroll går ut så här:

1. Öppna Health Check i Control Center.
2. Sortera fynd som inte uppfyller policyn efter allvarlighetsgrad.
3. Kontrollera Internet-exponerade tjänster och administratörsåtkomst först.
4. Redigera MFA, lösenord och sessionsämnen.
5. Identifiera breda brandväggsregler och validera med Log Viewer.
6. Kontrollera säkerhetskopiering, Hotfixes, loggning och rapportering.
7. Utvärdera skyddsfunktioner per regel.
8. Dokumentera legitima undantag istället för att åsidosätta dem utan kommentar.
9. Kontrollera igen för ändringar.
10. Dokumentera resultatet med datum, vem som genomförde granskningen och öppna punkter.

För återkommande granskningar räcker ofta fälten Fynd, Risk, Åtgärd, Ansvarig person, Status och Datum för ny granskning. Det är viktigt att fynden inte bara betraktas, utan bearbetas eller medvetet accepteras.

Gränser

Health Check är till hjälp, men har tydliga begränsningar.

• Han känner inte till miljöns fullständiga affärslogik.
• Den bedömer inte om en regel är tekniskt nödvändig.
• Det ersätter inte nätverkssegmentering eller zonindelningsmodeller.
• Den känner inte automatiskt igen varje riskfyllt specialfall.
• Det ersätter inte en extern revision eller en manuell kontroll av reglerna.
• Det står inte om varningar kommer att behandlas senare.

Det är därför du bör se Health Check som utgångspunkt. Det gör synliga avvikelser påtagliga, men den faktiska säkerhetskvaliteten kommer från bra arkitektur, rena processer och konsekvent underhåll.

Checklista för verksamheten

• Kör Health Check efter start och efter större förändringar.
• Prioritera fynd baserat på svårighetsgrad och exponering.
• WAN-Kontrollera tillgängligheten för portalerna WebAdmin, SSH, User Portal och VPN.
• Aktivera MFA för administratörer, portaler och fjärråtkomst.
• Rensa upp eller motivera breda brandväggsregler.
• Aktivera loggning i viktiga regler.
• Kontrollera säkerhetskopior och återställningsprocessen.
• Dokument snabbkorrigering och firmwareprocess.
• Ange endast åsidosättningar med motivering.
• Dokumentera hälsokontrollresultat regelbundet.

FAQ