Aktivera och verifiera MDR Threat Feeds på Sophos Firewall

MDR Threat Feeds ansluter Sophos MDR-tjänsten till Sophos Firewall. MDR-analytiker kan via Sophos Fusion (tidigare Sophos Central) skicka IPv4-adresser, domäner och URL:er som hör till en aktiv incident i den egna miljön till brandväggen. Brandväggen loggar eller blockerar sedan matchande trafik utan att en egen feedfil behöver underhållas manuellt.

En säker utrullning kräver mer än att slå på en omkopplare i WebAdmin. MDR-licensen, Sophos-Fusion-registreringen, den lokala åtgärden, nödvändig trafiksynlighet, loggmål och kontaktvägen till MDR-teamet måste stämma överens. En lokal status Log and drop bevisar ännu inte att en viss IoC har kommit fram eller att det berörda trafikflödet passerar de kontroller som behövs.

Benämningar i gränssnittet: De Sophos-Fusion-sökvägar som används här följer hjälpen för SFOS 22. Hjälpen för SFOS 23 använder fortfarande Sophos Central för samma molnanslutning. Om den egna versionen visar denna benämning öppnar du motsvarande Sophos-Central-sida. Namnet i sig säger ingenting om registrering, MDR-behörighet eller leverans av feeden. Send reports and logs to Sophos Central är fortfarande det dokumenterade namnet på loggningsalternativet.

MDR Threat Feeds i åtta steg

1. Kontrollera att Xstream Protection Bundle finns på brandväggen och att en aktiv MDR-behörighet finns i Sophos Fusion.
2. Under System > Sophos Fusion, kontrollera att rätt brandvägg är registrerad i rätt Sophos-Fusion-konto.
3. Dokumentera avsett Threat response mode och den operativa MDR-kontaktvägen i Sophos Fusion.
4. Under System services > Log settings, aktivera minst ett användbart loggmål för Active threat response.
5. Öppna Protect > Active threat response > MDR threat feeds och slå på funktionen.
6. Välj Log only för en kort kontrollerad pilot eller Log and drop för produktionsskydd efter godkänd verifiering och klicka på Apply.
7. Genomför positiva och negativa kontroller med Log Viewer, endpointkontext och Sophos Fusion.
8. Dokumentera Audit-ID, ansvariga, undantagsprocess, granskningsdatum och återställningsplan.

Viktigt: MDR Threat Feeds är bara en del av MDR-driften. De ersätter varken MDR-avtalet, endpointsensorer, incidentkommunikation, snäva brandväggsregler eller en testad återställningsväg. Ett brett undantag eller en okontrollerad inaktivering kan försvaga en pågående insats från MDR-teamet.

Vad MDR Threat Feeds gör

Sophos MDR-analytiker kan skicka hotinformation om en aktiv incident direkt till brandväggen via Sophos Fusion. Feeden är därför mer kundspecifik än en allmän global reputationslista. En överförd IoC kan vara en IPv4-adress, domän eller URL.

Den lokala brandväggsåtgärden avgör vad som händer vid en matchning:

• Log only loggar träffen men tillåter trafiken.
• Log and drop loggar och blockerar den matchande trafiken.

Sophos rekommenderar blockering för kända IoC:er. En kort pilot med Log only kan ändå vara lämplig om en befintlig miljö först behöver kontrollera synlighet, loggning och möjliga sidoeffekter. Piloten måste ha ett fast slutdatum. Utan en planerad övergång riskerar en aktiv MDR-integration annars att förbli permanent utan lokal blockering.

Threat response mode i Sophos Fusion och den lokala feedåtgärden är två olika nivåer. Läget i Sophos Fusion avgör vilka befogenheter MDR-teamet har att vidta åtgärder. Log only eller Log and drop avgör hur brandväggen hanterar en IoC som redan har överförts. Före utrullningen stäms båda inställningarna av mot MDR-avtalet och den interna incidentprocessen. Den aktuella Sophos-dokumentationen om Threat response mode skiljer mellan Collaborate, Authorize och Notify Only.

Skilj brandväggstelemetri från analytikernas åtgärder

Data flödar också i motsatt riktning: brandväggen levererar säkerhetshändelser för MDR-utredningar. För detta måste den vara registrerad i Sophos Central firewall management; på brandväggen måste Sophos Central services vara aktiverat och Send reports and logs to Sophos Central vara valt. MDR analyserar kontinuerligt säkerhetsloggar från Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection och Application Control. Tillsammans med data från endpoints, servrar och andra integrerade källor hjälper dessa händelser till att upptäcka skadlig aktivitet, IoC:er och försök till lateral förflyttning. Inkommande brandväggstelemetri är dock inte den kundspecifika IoC-feed som MDR-analytiker skickar tillbaka till brandväggen.

Vid en kritisk incident kan MDR-teamet exempelvis avsluta VPN-sessioner för komprometterade användare. Det är en incidentresponsåtgärd som analytikerna utför inom ramen för sina tilldelade befogenheter, inte en automatisk följd av en feedträff eller en lokal klick- eller CLI-instruktion. Med Authorize kan teamet reagera på aktiva hot utan att först rådgöra med de angivna kontaktpersonerna; med Collaborate samordnas åtgärderna med dessa kontakter. Detta innebär inte obegränsade befogenheter att vidta åtgärder på alla enheter eller integrationer. VPN-sessioner i produktion avslutas inte som funktionstest.

För ingrepp via Live Response måste Live Response vara tillåtet på den berörda enheten. Isolera Sophos Endpoint och undersök med Live Response förklarar förutsättningarna och det säkra förfarandet. Microsoft 365-åtgärder som att blockera eller tillåta inloggningar, återkalla aktiva sessioner och inaktivera Inbox Rules kräver att responsintegrationen är konfigurerad; för dessa gäller det separata förfarandet under MDR- och XDR-integrationer. Brandväggsloggning eller en levererad MDR-IoC aktiverar inte automatiskt dessa ingrepp.

De cybora.io Threat Feeds som Avanet använder för Sophos Firewall är däremot Third-Party Threat Feeds, inte Sophos MDR Threat Feeds eller MDR-feedar som Avanet har skapat. Konfigurationen följer förfarandet för tredjepartsfeedar; den ger inte Sophos-MDR-teamet några ytterligare befogenheter att vidta åtgärder.

Förstå ordningsföljden och livscykeln

SFOS 22 bearbetar Active Threat Response i ordningen MDR, NDR Essentials, Sophos X-Ops och Third-Party Threat Feeds. Om en IoC matchar i MDR med Log and drop blockerar brandväggen trafiken, loggar den under MDR och kontrollerar inte de efterföljande feedarna. Med Log only respektive Monitor kan separata händelser skapas för MDR, X-Ops och Third-Party Feeds. Vid Log only eller olika modulåtgärder ska inget allmänt tillåtande undantag förutsättas; ta hänsyn till övriga konfigurerade åtgärder och kontrollera trafik- och loggbevis.

Enskilda MDR-IoC:er skapas eller redigeras inte i WebAdmin. MDR-analytiker lägger till dem via Sophos Fusion och tar bort dem där. Båda åtgärderna loggas med åtgärd och analytikerns identitet som audit_ID. Dessa administrationshändelser söks i detaljvyn Admin i Log Viewer eller i Sophos Fusion Firewall Task Queue och ska inte förväxlas med trafikträffarna under Active threat response. Lokalt styr du bara om MDR-feeden är aktiv och om matchande trafik ska loggas eller dessutom blockeras. Threat Exclusions är däremot globala och gäller för alla Active-Threat-Response-moduler.

Dokumentationen för SFOS 22 anger ingen giltighetstid för MDR-IoC:er som brandväggsadministratören kan ställa in. Därför får inget utgångsdatum härledas från det lokala gränssnittet. Om en post är tveksam eller möjligen inaktuell sparas audit_ID, IoC och tidpunkt, och statusen stäms av med MDR-teamet. Detta är också viktigt vid återställning: en ändring från Log and drop till Log only påverkar alla MDR-IoC:er som för närvarande har levererats. En Threat Exclusion kan dessutom försvaga NDR, X-Ops och Third-Party Feeds.

Kontrollera förutsättningarna noggrant

Licens och Sophos Fusion

MDR Threat Feeds kräver Xstream Protection Bundle på brandväggen. Licenstabellen för SFOS 22 anger dessutom Sophos MDR Essentials eller Sophos MDR Complete i Sophos Fusion. Den aktuella Sophos-Fusion-dokumentationen benämner tjänstevarianterna MDR och MDR Plus. Kontrollera därför den aktiva MDR-behörigheten i det egna Sophos-Fusion-kontot i stället för att utgå enbart från en äldre produktbenämning. Xstream-paketet i sig innehåller ingen MDR-tjänst.

Brandväggen måste vara registrerad i rätt Sophos-Fusion-konto. Under System > Sophos Fusion kontrolleras registrering samt överföring av rapporter och loggar. Hela anslutningsförfarandet beskrivs i Anslut Sophos Firewall till Sophos Fusion.

Dessutom måste Sophos MDR-tjänsten vara konfigurerad. Enbart brandväggsregistrering och licenskontroll ersätter inte denna konfiguration. Innan funktionen aktiveras lokalt ska du tillsammans med den MDR-ansvariga bekräfta att tjänsten är konfigurerad för rätt kund och att Threat response mode har valts medvetet. Sophos kräver minst en behörig kontaktperson innan ytterligare MDR-inställningar kan konfigureras eller tjänsten kan användas. För den ytterligare endpointkontexten via Synchronized Security anger licenstabellen för SFOS 22 även en Intercept X-licens i Sophos Fusion. Denna kontext garanteras inte av enbart Xstream-paketet.

Sophos MDR: konfigurera kontakter och Threat Response beskriver hela det centrala förfarandet med kontaktroller, Collaborate-reservlösning, enhetsåtkomst och säker kontroll av sparade värden. Det ersätter inte den efterföljande lokala feedkonfigurationen.

Före aktivering måste även ansvarsfördelningen vara klar:

• Vem får ändra Threat response mode i Sophos Fusion?
• Vem tar emot ett MDR-samtal eller en följdfråga utanför kontorstid?
• Vem får godkänna ett undantag?
• Var dokumenteras Audit-ID, Incident-ID och tekniska bevis?
• Vilka system får isoleras vid bekräftad kompromettering?

Aktivera loggmål

Under System services > Log settings aktiveras minst ett av dessa mål på raden Active threat response:

• Local reporting för Log Viewer och lokala rapporter
• en konfigurerad Syslog server för SIEM eller SOC
• Central reporting för Sophos Fusion

Kolumnen Central reporting visas först när Send reports and logs to Sophos Central är aktiverat på Sophos-Fusion-sidan. XGS 87/87w och 107/107w stöder inte lokal rapportering. Där behövs Central Reporting eller Syslog.

När loggmålen har valts under System services > Log settings, klicka på Apply. Ladda sedan om sidan och kontrollera att de avsedda målen fortfarande är valda på raden Active threat response. Detta bekräftar den sparade konfigurationen. Den faktiska loggtransporten och leveransen av incidentaviseringar kontrolleras separat.

För aviseringar kontrolleras även System services > Notification list. Aktivering av ett loggmål anger transportvägen men bevisar varken faktisk leverans eller korrekt larmhantering.

Synlighet för IP, domän och URL

En IoC påverkar bara trafik som brandväggen kan behandla på rätt sätt. För vidarebefordrad trafik till en destinations-IP krävs en lämplig brandväggsregel. Domänmatchningar kräver Application Classification eller en IPS-policy i den aktuella regeln. För en fullständig HTTPS-URL-sökväg krävs Web Proxy med dekryptering eller DPI med en lämplig SSL/TLS-Inspection-regel.

Trafik riktad till systemtjänster under Administration > Device access, exempelvis WebAdmin, VPN Portal och VPN, kan kontrolleras utifrån en skadlig IPv4-källadress. För inkommande vidarebefordrad DNAT- eller WAF-trafik måste även Remote source match (inbound traffic) aktiveras under System services > Log settings > Active threat response för att få den förväntade loggsynligheten.

Oklar begränsning för ATR/X-Ops: Den officiella beskrivningen och trafikmatrisen motsäger varandra när det gäller matchningar av destinationsadresser och lokala källadresser för Sophos X-Ops. För dessa fall är det inte tillförlitligt klarlagt vare sig att stöd finns eller att stöd saknas. De länkade trafik- och moduluppgifterna är därför inte ett godkänt konfigurationsunderlag för dessa fall. Ingen MDR-trafikriktning härleds från dem, och ingen skyddseffekt förutsätts för de berörda X-Ops-fallen. Före en ändring som bygger på detta krävs ett bindande klargörande från Sophos eller ett uttryckligen godkänt produkttest. Länkarna nedan löser inte denna motsägelse.

Den allmänna logiken för trafik, moduler och inspektion beskrivs i Konfigurera Sophos Firewall Threat Feeds och använd dem säkert. Där förklaras också varför detektering av en domän eller URL kan utebli utan rätt klassificering respektive dekryptering.

Konfigurera MDR Threat Feeds

1. Logga in i WebAdmin med ett personligt administratörskonto.
2. Öppna Protect > Active threat response > MDR threat feeds.
3. Slå på MDR threat feeds.
4. Välj Log only som Action för en tidsbegränsad pilot eller Log and drop efter godkänd verifiering.
5. Spara med Apply.
6. Ladda om sidan och kontrollera att omkopplarens läge och Action har sparats.
7. Kontrollera tidsstämpel, administratör och ändring i Audit Trail.
8. Kontrollera i Sophos Fusion att brandväggen är online och att MDR är kopplat till rätt kund respektive klientorganisation.

Gör inte omfattande ändringar av loggning, inspektion, undantag och Action samtidigt. En stegvis utrullning gör det tydligt vilken ändring som orsakade en träff eller en sidoeffekt.

Verifiera effekten med tillförlitliga bevis

Det finns ingen allmän ofarlig MDR-testindikator angiven för detta arbetsflöde. Att besöka en verklig skadlig domän eller en känd skadlig IP-adress är därför ingen lämplig verifiering. Den tekniska kontrollen delas upp i flera nivåer som kan beläggas var för sig. Ett eget Third-Party-test bevisar bara den trafik- och inspektionsväg som testats, inte att analytikerteamet har levererat en MDR-IoC.

Konfiguration och transport

1. Kontrollera MDR-omkopplaren och önskad Action på brandväggen.
2. Kontrollera Sophos-Fusion-registreringen och MDR-licensen.
3. Bekräfta Active-Threat-Response-loggning för det förväntade målet.
4. Kontrollera i Sophos Fusion att MDR- eller brandväggsuppgifter har bearbetats korrekt.
5. Vid en verklig MDR-incident, stäm av förväntad IoC och tillhörande Audit-ID med MDR-teamet.

Sophos Fusion Firewall Task Queue visar MDR- och API-uppgifter. Success bekräftar att Sophos-Fusion-uppgiften har bearbetats, men ännu inte effekten på ett konkret trafikflöde. Vid Partial Success eller Failed sparas uppgifter om berörd brandvägg, Entity, Action och Credential ID och jämförs med den lokala konfigurationen.

Undersök träffar i Log Viewer

Under Log viewer > Active threat response sparas minst följande information:

• tidsstämpel, brandvägg och vid HA den nod som bearbetade trafiken
• Action och feednamn
• käll- och destinations-IP, domän eller URL
• portar och protokoll
• Event-ID och övriga detaljfält
• för MDR även tillhörande audit_ID från administrationshändelsen eller Task Queue

Trafikbevis och analytikeråtgärd är separata bevis. Att fältet audit_ID saknas i trafikposten är i sig inget leveransfel. Kopplingen görs utifrån IoC, brandvägg och tidsintervall och bekräftas med MDR om något är oklart.

Med Synchronized Security kan brandväggen även visa användare, värd och process för hanterade Windows-endpoints. I Log Viewer är Process user och Executable relevanta för detta, liksom host_process_user, endpoint_id och execution_path i detaljvyn. På macOS visas inte dessa processdetaljer. Där identifieras endpointen via käll-IP och Sophos-Fusion-data.

Vid en detektering begär brandväggen dessa detaljer från de endpoints som hanteras via Sophos Fusion. Hjälpen beskriver visningen för Windows 7 och senare. Det är ingen rekommendation att använda Windows 7 och ingen garanti för aktuellt endpointstöd för alla äldre Windows-system. På macOS kan ett generiskt meddelande som Active threat C2/Generic-C deleted visas i stället. Det ersätter varken kopplingen till värden via käll-IP eller beviset på vilken brandväggsåtgärd som tillämpades på trafiken.

Den lokala sammanfattningen finns under Reports > Network & threats > Active threat response i listan Synchronized IoC. Översikten över Sophos-Firewall-tjänster och loggfiler beskriver även var atr.log hör hemma. En enskild loggpost bedöms aldrig isolerat: brandväggs-, DNS-, webb-, IPS-, endpoint- och Sophos-Fusion-händelser från samma tidsintervall ska ses tillsammans.

Positiv och negativ kontroll

En pilot i produktionsmiljö bör omfatta minst dessa två fall:

1. Positiv: Vid en verklig IoC eller incident som bekräftats av MDR-teamet sparas en spårbar trafikpost med korrekt Action och den tillhörande analytikeråtgärden med Audit-ID separat och stäms av mot varandra. Ingen ytterligare trafik till skadlig infrastruktur genereras för detta.
2. Negativ: En jämförbar legitim verksamhetsprocess förblir tillgänglig och orsakar ingen oavsiktlig MDR-blockering.

Utan en verklig incident skapas ingen artificiell MDR-IoC. I stället kontrolleras konfiguration, uppgiftsbearbetning, loggtransport och kommunikationsväg. För ett helt kontrollerbart trafiktest lämpar sig en egen Third-Party-pilotfeed bättre än ett externt skadligt mål.

Behandla MDR-träffar som incidenter

En MDR-träff är en stark signal, men loggposten ensam förklarar ännu inte hela angreppsförloppet. Ett metodiskt förfarande är:

1. Spara tidpunkt, Action, IoC, feednamn, Event-ID och audit_ID.
2. Identifiera berörd värd och användare via käll-IP, DHCP, Synchronized Security och endpointdata.
3. Öppna tillhörande MDR-ärende, detektering och övriga enhetshändelser i Sophos Fusion.
4. Korrelera brandväggs-, DNS-, webb-, IPS- och endpointloggar från samma tidsintervall.
5. Klargör med MDR-teamet varför IoC:n lades till och vilken åtgärd som är planerad.
6. Starta den interna incidenthanteringsprocessen vid bekräftad kompromettering.
7. Besluta först därefter om sanering, ytterligare regler eller ett snävt undantag.

Audit-ID identifierar MDR-analytikerns åtgärd. I Log Viewer, klicka först på knappen för detaljvyn och välj sedan Admin i listrutan. Spara där åtgärden och audit_ID för tillägget eller borttagningen. Alternativt finns analytikeråtgärden under My Products > Firewall management > Tasks Queue i Sophos Fusion. Vid en fråga till MDR ska Audit-ID ingå i ärendet tillsammans med brandväggens serienummer, tidpunkt, IoC, Event-ID och Incident-ID. En loggad borttagning bevisar en administrationsåtgärd, inte att den berörda endpointen har sanerats.

Hantera undantag kontrollerat

Under Protect > Active threat response > Add threat exclusions kan värd-/nätverksundantag och hotundantag skapas. Dessa undantag gäller över modulgränserna. Ett undantag för en MDR-träff kan därmed även försvaga X-Ops, NDR eller Third-Party Threat Feeds.

Före ett undantag dokumenteras IoC, berörd verksamhetsprocess, MDR-ärende och bekräftelse på falskt positivt resultat. Undantaget hålls så snävt som möjligt och förses med motivering, ansvarig, ärendenummer samt gransknings- eller utgångsdatum. Hela klientnät eller breda domänområden är ingen lämplig snabb lösning.

Threat-Feed-konfigurationer kan inte importeras eller exporteras separat, men det kan Threat Exclusions. MDR-feedinställningarna kan inte heller överföras via Import existing configuration till den initiala konfigurationen av en ny Sophos-Fusion-brandväggsgrupp. Efter migrering, återställning eller utbyte kontrolleras därför funktion, Action, loggning och Sophos-Fusion-koppling uttryckligen på nytt.

Om ingen MDR-träff visas

Kontrollen börjar inte med att starta om en tjänst. Först skiljs lagren åt:

1. Stämmer MDR-licens, Sophos-Fusion-konto, brandväggsregistrering och Threat response mode?
2. Är MDR Threat Feeds aktivt lokalt och är Action sparad?
3. Har MDR-teamet faktiskt överfört den aktuella IoC:n för denna miljö?
4. Visar Sophos Fusion Firewall Task Queue Success, Partial Success, Failed eller fortfarande Pending?
5. Är Active-Threat-Response-loggar aktiverade lokalt, till Syslog eller i Sophos Fusion?
6. Går trafiken genom förväntad brandvägg, regel och inspektion?
7. Finns IoC:n i Active-Threat-Response-, webb- eller SSL/TLS-undantag?
8. Stämmer tidsintervallet och, vid HA, den undersökta noden?

För motor- och feedstatus kan atr.log korreleras tidsmässigt med Log Viewer och Sophos Fusion Firewall Task Queue. Loggar läses bara. Odokumenterade ändringar av feeddata, databaser eller tjänster är inget standardsteg. Om orsaken förblir oklar sparas CTR, relevanta loggar, Task-ID, Audit-ID, build och tidpunkt för Sophos MDR respektive Sophos Support.

Återställning och ändringskontroll

Före aktivering dokumenteras omkopplarens tidigare läge, Action, loggmål och befintliga undantag. Vid oväntad påverkan på verksamheten införs inte omedelbart ett brett undantag.

1. Spara berörd träff och dokumentera verksamhetspåverkan.
2. Informera MDR-teamet med Audit-ID och incidentuppgifter.
3. Om det godkänts av ansvarig, ändra tillfälligt den lokala Action från Log and drop tillbaka till Log only.
4. Endast om detta inte heller räcker och MDR samtycker återställs feeden kontrollerat till det dokumenterade tidigare tillståndet.
5. Kontrollera samma verksamhetsprocess och effekten i loggarna på nytt efter varje ändring.
6. Åtgärda orsaken och återinför produktionsskyddet med ett nytt granskningsdatum.

I HA-miljöer kontrolleras konfiguration och status på aktuell Primary. Loggarna finns på den nod som bearbetade trafiken. Efter en kontrollerad failover verifieras Sophos-Fusion-anslutning, feedstatus, nya loggposter och verklig trafik på nytt. Avbrottsfri MDR- eller loggkontinuitet förutsätts inte.

Checklista

• Xstream Protection Bundle är aktivt
• aktiv MDR-behörighet finns i Sophos Fusion
• brandväggen är registrerad i rätt Sophos-Fusion-konto
• Threat response mode och MDR-kontaktväg är dokumenterade
• loggmål för Active Threat Response är aktiverat
• MDR Threat Feeds är påslaget
• Action är medvetet vald och piloten har ett fast slutdatum
• trafiksynlighet för IPv4, domän och URL är kontrollerad
• Remote source match för DNAT/WAF är aktiverat vid behov
• Task Queue och lokal status har jämförts
• Audit-ID och incidentprocess är kända
• endpointkontext och plattformsbegränsningar är kontrollerade
• undantag har ansvarig och granskningsdatum
• återställningsplan och HA-kontroll är dokumenterade

Vanliga frågor