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.

Hälsokontrollen introducerades med Sophos Firewall v22. Funktionen utvärderar konfigurationer mot bland annat bästa praxis och standarder som CIS benchmarks. Med SFOS 22.0 MR1 har den underliggande CIS-kontexten också uppdaterats.

Videoinstruktioner

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.

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 centrala 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.

Utvärdera poäng och status korrekt

Health Check är användbart, men ingen leverantörsneutral säkerhetsrevision. Det premierar även 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. 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 Central 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, Central 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 Central-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 kan du se antalet kontrollerade konfigurationer, de kompatibla punkterna och de icke-kompatibla punkterna. Sophos visar icke-kompatibla poster efter svårighetsgrad. 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 test om konfigurationen är kompatibel, inte kompatibel eller manuellt åsidosatt. Dessa tre tillstånd är viktigare för driften än det rena procentvärdet.

• Kompatibel: Den markerade konfigurationen överensstämmer med respektive policy. Efter stora förändringar bör de fortfarande vara tekniskt validerade.
• Icke-kompatibel: Den markerade konfigurationen följer inte policyn. Risk, exponering och genomförbarhet måste bedömas.
• Manuell åsidosättning av policystatus: Konfigurationen uppfyller inte policyn, men markerades manuellt som kompatibel. Denna status bör endast användas med motivering, ägare och återinlämning.

Under Action erbjuder vyn direkta arbetssteg beroende på fyndet. Fix now leder till lämplig konfigurationssida, Override status markerar ett icke-kompatibelt fynd som compliant och Undo override tar bort åsidosättningen. Detta är praktiskt, men ersätter inte en bedömning: Health Check vet inte automatiskt om en likvärdig kontroll faktiskt finns 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. SFOS 22.0 MR1 korrigerade felaktiga Doesn't comply-resultat för brandväggsregler och för NDR Essentials på virtuella brandväggar. En uppenbart felaktig status är därför varken ett skäl för en riskfylld konfigurationsändring eller en förhastad override.

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 Central. 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 Central och lämpliga licenser. Avanet-bedömning: valfritt. 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 Central. 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 Central. Standard: CIS, Allvarlighet: Låg. Svårighetsgraden verkar låg, men i en nödsituation är punkten extremt viktig. Återställningsprocessen bör också testas.
• 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. Uppdateringarna är automatiskt aktiva som standard, men status och senaste lyckade uppdatering bör ändå kontrolleras. Firmware för Access Points och RED-enheter laddas bara ned och installeras separat eftersom en omstart krävs. I Air Gap-miljöer behövs 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 eftersom CA distribution, undantag, pilotfas och felsökningsprocess är nödvändiga.
• 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 Central 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. En bra recension sorterar därför inläggen inte bara efter teknisk svårighetsgrad, utan även efter exponering och operativ risk.

This order has proven successful:

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. Central, Reporting eller NDR-Findings utvärderar 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 regelbundna hygien- och skyddsfunktioner. Sedan drifts- och ekosystemämnen.

Typiska fynd och lämpliga åtgärder

WebAdmin, User Portal eller VPN portalen är för bred för att nå

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 autentiseringsuppfyllning. 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?
• Is logging active so that hits are visible?
• 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 och verifiera recensionen

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 dock inte missförstås som en saneringsfunktion. De är bara vettiga om kravet medvetet uppfylls annorlunda eller om det finns en kompenserande kontroll. An example is MFA: If an environment uses Microsoft Entra ID SSO with MFA as mandatory login control, a local MFA finding can be overridden for technical reasons depending on the design. Utan en sådan motivering kvarstår risken, även om hälsokontrolldisplayen ser bättre ut.

Om en punkt åsidosätts ska den dokumenteras:

• Why is the recommendation not suitable?
• Vem godkände beslutet?
• Gilt die Ausnahme dauerhaft eller nur temporär?
• 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å Umgebungen reicht ofta en kurze Tracking-Liste med diesen Feldern:

• 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, biljett, ändra ID eller revisionslogganteckning.

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 att ha loggat eller rapporterat ändringar, kontrollera om nya händelser faktiskt är synliga lokalt, i Sophos Central eller i sysloggen.
• Ställ in en återinlämning 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 icke-kompatibla fynd efter svårighetsgrad.
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, processor och öppna punkter.

För återkommande granskningar räcker ofta fälten Hitta, Risk, Åtgärd, Ansvarig person, Status och Återinlämnande. 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 inloggning av viktiga regler.
• Kontrollera säkerhetskopior och återställningsprocessen.
• Dokument snabbkorrigering och firmwareprocess.
• Ange endast åsidosättningar med motivering.
• Dokumentera hälsokontrollresultat regelbundet.

FAQ