Förstå Sophos Next-Gen SIEM och planera datalagringen

Sophos Next-Gen SIEM är ett valfritt tillägg till Sophos XDR Powered by Secureworks och Sophos MDR. Kontot måste ha uppgraderats till Sophos Fusion före användning. Den tekniska administratörshjälpen beskriver 13 månaders datalagring som standard och möjlighet till förlängning upp till 10 år. Dessutom ingår hot- och efterlevnadstelemetri samt egna integrationer utöver de färdiga XDR-/MDR-integrationerna. Denna bedömning gäller granskningsläget den 28 oktober 2026; produktsidans avvikande uppgift om ett år förklaras nedan ur ett inköpsperspektiv.

Inför beslutet bör man först dokumentera vilka datakällor och lagringstider som behövs. Därefter får man tilläggets konkreta omfattning bekräftad för den egna tenantmiljön och kontrollerar med en liten pilotkälla att de avsedda händelserna faktiskt läses in och går att hitta igen. En befintlig XDR- eller MDR-licens är i sig inget bevis på att det valfria tillägget är aktiverat.

När Next-Gen SIEM passar uppgiften

SIEM står för Security Information and Event Management: händelsedata samlas in centralt och görs tillgängliga för analys. Next-Gen SIEM utökar den gemensamma dataarkitekturen för XDR/MDR med längre lagring och analyser av efterlevnad. Det är särskilt värt att utvärdera när man behöver historiska händelser över längre perioder eller vill läsa in en källa via en egen integration.

Om uppgiften till att börja med är att konfigurera en befintlig produktintegration börjar man med MDR- och XDR-integrationer i Sophos Fusion. Den artikeln förklarar dataflödet och kontrollerna i drift. Syslog-anslutning för Sophos Firewall behandlar transporten av brandväggsloggar till en mottagare. Den besvarar inte vilken Next-Gen SIEM-omfattning som har köpts eller aktiverats för en källa.

Den primära plattformen för detektion, utredning, respons och automatisering är fortfarande Sophos XDR. Next-Gen SIEM kompletterar dessa arbetsflöden med datainsamling inriktad på efterlevnad, historiska underlag och längre lagring. SIEM-tillägget är därför inte ett generellt krav för XDR-funktioner för detektion eller respons som redan är licensierade; omvänt aktiverar inte XDR ensamt de ytterligare SIEM-tjänsterna.

Avanet rekommenderar att man inte väljer tillägget enbart för att få så lång retention som möjligt. Retention betyder här hur länge data sparas. Avgörande är vilka händelser man senare behöver för vilka frågor, vem som analyserar dem och hur länge de behöver vara tillgängliga. Längre lagring hjälper föga om den händelsekategori som behövs inte levereras eller om viktiga fält saknas.

Sophos beskriver även färdiga dashboards för efterlevnad. Sådana analyser stödjer arbetet med att ta fram belägg, men ersätter varken kontroll av datatäckningen, juridisk bedömning eller certifiering. Tillägget innebär inte att efterlevnad automatiskt är uppnådd.

Klargör tenantmiljö och erbjudande före införandet

Före inköp dokumenterar man rätt tenantmiljö, vilken XDR/MDR-produkt som används och den faktiska statusen för Fusion-uppgraderingen. Ett tillkännagivande eller ett planerat uppgraderingsdatum räcker inte som godkännande för användning i drift. Därefter får man via Sophos-partnern bekräftat om Next-Gen SIEM är tillgängligt för kontot och vilken lagring och vilka integrationstjänster det konkreta erbjudandet omfattar.

Sophos beskriver en användar- och serverbaserad prismodell utan avgifter för datainläsning, alltså utan en avgift baserad på den inlästa datavolymen. Det är en beskrivning av prismodellen, inte en offert eller ett löfte om obegränsad teknisk kapacitet. Före beställning måste beräkningssätt, avtalstid, önskad förlängning av lagringstiden, integrationsomfattning och eventuella förutsättningar för tredjepartsprodukten klargöras. Beskrivningen innebär i synnerhet inte gratis tredjepartslicenser eller garanterade gränser för genomströmning eller antal händelser.

För egna integrationer är möjligheten att skapa egna dataintegrationer bekräftad. Det innebär ännu inte att det finns en verifierad konfigurationsmetod för varje källa. Före piloten behövs därför en beskrivning som passar den konkreta källan och omfattar överföring, autentisering, händelseformat, fältmappning och stödda analyser. Befintliga connectormenyer eller frågor får inte utan kontroll överföras till en egen integration. Vägen till dashboarden beskrivs nedan; detta innebär inte att det finns en universell konfigurationsmetod för varje egen källa.

Bekräfta uttryckligen licensantal och collector-väg

Next-Gen SIEM kan inte köpas som en fristående produkt. Antalet abonnemang måste motsvara det totala antalet licensierade XDR- och MDR-användare och servrar; servrar får inte utelämnas vid beräkningen. Stäm av det konkreta beståndet och erbjudandet med partnern i stället för att endast använda en pilotgrupp eller datavolymen som licensantal. Utöver standardperioden på 13 månader kan förlängningar av lagringstiden till tre, fem, sju eller 10 år köpas som tillval; de aktiveras inte automatiskt genom en befintlig XDR-/MDR-licens. De återställer inte i efterhand historik vars lagringstid har löpt ut och bevisar ingen juridisk efterlevnad.

Licensriktlinjerna som gäller från 16 oktober 2026 anger dessutom en användningsgräns på 1 GB rådatainläsning per dag, sammanlagt för alla datakällor. Tabellen licensierar per användare och server, men meningen om datamängd anger inte uttryckligen om kvoten gäller per subscription eller tenant. Beräkna därför varken 1 GB × användare och servrar eller anta en fast gräns på 1 GB för tenanten. Före dimensionering eller beställning krävs bindande bekräftelse av beräkningsenhet, sammanräkning och vad som händer vid överskridande. Ett pris utan volymbaserade ingestionavgifter innebär inte obegränsad användning.

Även antalet Retention Add-on-subscriptions måste motsvara det totala antalet NG-SIEM-subscriptions. Därav följer inte förlängd lagring för en fritt vald delmängd eller en enda källa.

För Syslog-integrationer stöder äldre Sophos Log Collectors inte hela lagringsomfattningen i Next-Gen SIEM. För detta rekommenderar Sophos byte till XDR Data Collectors; den befintliga runbooken för collector-migrering förklarar provisionering, driftsättning, växling av källor och godkännande. Befintliga API-integrationer behöver inte konfigureras om enbart på grund av detta collector-byte. På en delad SVA förblir NDR en separat arbetslast och får inte stängas av oavsiktligt vid Syslog-övergången. Den nya collectorn ersätter inte kontrollen av rätten till tillägget, källformatet och den faktiska lagringstiden.

SIEM-hubben ordnar befintliga anvisningar efter planering, källinsamling, transport och parserkontroll. Det praktiska HTTP-/parserexemplet binder ihop stegen med en syntetisk laboratoriekälla; den praktiska verifieringen i en tenant återstår.

Egna data: skilj transport, normalisering och detektion åt

En Custom Integration transporterar data från en källa som inte har optimerats av Sophos till XDR. Det bekräftar inte i sig normalisering, sökning eller detektion för källan. Custom Parsers mappar loggfälten till de standardiserade XDR-händelsescheman som stöds. Först därefter går det att kontrollera om de fält som behövs för den önskade sökningen, en Detector eller en Custom Detection Rule finns.

Custom Parsers kräver en Next-Gen SIEM-prenumeration. Admin och Super Admin får hantera dem; andra roller kan bara se listan över konfigurerade parsers. Meddelanden som ingen parser matchar faller tillbaka på schemat generic. De kan ge sammanhang för Cases och Custom Rules, men visas bara i sökresultat med avancerade sökparametrar. Att en enkel sökning inte ger någon träff bevisar därför inte att inga data har lästs in.

Inte heller korrekt normaliserade data utlöser automatiskt varje Detector som passar schemat. Sophos anger vissa detektionsvägar som stöds och vilka fält de kräver; andra Detectors garanteras inte. Den önskade detektionen godkänns därför separat med lämpliga testhändelser. Det utannonserade AI-stödet ersätter inte denna kontroll.

En nyskapad Custom Parser är avstängd som standard. Den testas upprepade gånger med olika exempelmeddelanden, sparas och aktiveras först därefter separat. Ändringar i en parser som redan är aktiv börjar däremot gälla omedelbart när de sparas; testa därför noggrant innan du sparar. Överlappande Confirm Strings kan tilldela meddelanden till fel parser; därför ingår den extractor path som faktiskt används i kontrollen.

Sophos underhåller eller uppdaterar inte Custom Parsers. En ansvarig operatör måste kontrollera fältmappning, tidsstämplar samt sök- och detektionsresultat på nytt efter ändringar i källformatet eller parsern. Under piloten dokumenteras datainläsning, normalisering och önskad analys som tre separata resultat; en grön transportstatus räcker inte.

Praktisk konfiguration beskrivs i Custom HTTP Ingest, S3-varianterna, Azure Event Hubs och Storage och Custom Parser-runbooken. För varje variant förblir transport, schema och önskad analys separata acceptansresultat.

Öppna NG-SIEM-dashboarden för kontroll av underlag

Med tillägget aktiverat kan den tillhandahållna vyn läggas till i den personliga dashboardlistan:

Öppna Dashboards > Manage dashboards.
Välj Find dashboards och lägg till NG-SIEM i listan.
Öppna dashboarden från listan och jämför de visade uppgifterna med källinventeringen, tidsperioden och förväntade händelser.

NG-SIEM-dashboarden innehåller widgets om åtkomstkontroll, nätverkssäkerhet och revisionshändelser. Sophos beskriver även ett ISO 27001-dashboardexempel som samlar autentisering, ändringar, nätverks- och brandväggshändelser, e-post- och filaktivitet samt detektions- och Case-flöden. Vilken information som faktiskt finns för det egna underlaget beror på de anslutna källorna och deras datakvalitet; visningen är varken en ISO-certifiering eller en automatisk bekräftelse på efterlevnad.

Den allmänna dashboardguiden förklarar personliga listor, tillgängliga vyer och PDF-export. Om NG-SIEM saknas kontrolleras först tenantmiljö, tillägg och behörighet; en tom vy granskas mot datakälla och tidsperiod. Varken saknade eller gröna widgets ersätter kontrollen av de underliggande händelserna.

Den aktuella produktspecifika NG-SIEM-hjälpen från 1 oktober 2026 beskriver denna ingång. Den äldre gemensamma dashboardhjälpen från 17 september nämner fortfarande endast TAC-dashboarden. Det är en dokumentationsskillnad, ingen garanti om en overifierad tenantvy. Om ingången saknas trots en passande offert ska faktisk provisionering klargöras; skapa inte en andra integration på misstanke.

Skilj lagring, sökfönster och rådata åt

13 månader i administratörshjälpen, ett år på produktsidan

Den tekniska översikten från den 1 oktober 2026 anger 13 månaders standardlagring. Den offentliga produktsidan anger däremot ett år vid granskningen den 28 oktober. Båda nämner förlängningar till tre, fem, sju eller tio år. Skillnaden tolkas varken som en bekräftad produktändring eller som enbart en annan avrundning; en entydig förklaring från Sophos saknas.

För den tekniska bedömningen i denna artikel är de 13 månaderna i den produktspecifika administratörshjälpen referensen. Före en beställning eller ett bindande löfte om lagringstid måste ändå den period som gäller för den specifika tenanten, datatyperna och erbjudandet bekräftas. Bekräftelsen ska ingå i källinventeringen. Om verksamheten exempelvis behöver mer än tolv månaders historik får den extra tiden inte förutsättas enbart utifrån den allmänna produktmarknadsföringen. Lagringsinventeringen och godkännandet nedan kontrollerar den avtalade omfattningen; de löser inte källkonflikten genom en antagen tidsperiod.

Sökperiod och åtkomst till rådata

Lång lagring innebär inte att en godtyckligt stor fråga kan köras på en gång. Den aktuella schemahjälpen tillåter för normaliserade Events högst 31 dagar per fråga, med valfritt startdatum inom faktiskt bevarade data. Dela längre utredningar i lämpliga fönster. Sökning i detections är separat.

För @raw och original_data anger den nyare SQL-till-QL-migrationsguiden från 15 september 2026 en separat åtkomstgräns på 20 dagar. En begäran utanför detta omfång avvisas och förkortas inte tyst till tillåtet intervall. Den äldre Query Language-hjälpen nämner också 20-dagarssteg; det garanterar inte tillgång till äldre rådata. Uppdelning gör inte äldre Raw-data automatiskt tillgängliga. Sökgränsen bevisar varken fysisk radering efter 20 dagar eller generell förkortning av normaliserad lagringstid.

Data Lake Search och export förklarar schemaval, frågegränser, historiska fönster och fullständigt exportunderlag. Regeldriften skiljer en lyckad sökning från en kontinuerligt utvärderad detection- eller suppressionregel.

Skapa en lagringsinventering för varje källa

Inventeringen hör hemma i driftdokumentationen, inte bara i erbjudandet. För varje källa dokumenterar man följande; olika händelsekategorier från samma applikation kan behöva egna poster:

Källsystem, källans tenantmiljö, händelsekategorier och ansvarig person.
Syftet med datainläsningen och den konkreta fråga som en senare sökning eller verifiering ska besvara.
Nödvändiga fält, exempelvis händelsetid med tidszon, åtgärd, resultat och en identitet som lämpar sig för utredningen.
Dataklassning, tillåtet innehåll och godkännande för överföring och åtkomst.
Önskad lagringstid med motivering samt den bekräftade omfattning som faktiskt gäller.
Integrationsmetod, nödvändiga behörigheter och ansvarig för inloggningsuppgifterna, utan att kopiera hemligheter till inventeringen.
Start för datainläsningen, förväntad bearbetningsfördröjning och en reproducerbar testhändelse.
Verifierad sökmetod, äldsta hittade post, senaste lyckade kontroll och nästa granskningsdatum.
Tillvägagångssätt vid avbrott, byte av källa, ändrad lagringstid och avveckling.

Produktuppgiften 13 månader, med möjlighet till förlängning upp till 10 år anges inte automatiskt som faktisk lagringstid för varje befintlig post. För den egna källan måste tillämpningsområde, start och åtkomst till historiska data klargöras. Man får inte heller förutsätta retroaktiv import av gamla data eller återställning av data vars lagringstid redan har löpt ut.

Exempel på en pilotkälla

Följande exempel är en planeringspost, inte en Sophos-konfiguration eller en verifierad connector. Värdena är fritt valda krav för en fiktiv verksamhet:

Källa: intern verksamhetsapplikation, testmiljö
Händelser: lyckad inloggning och administrativ rolländring
Syfte: spåra vem som ändrade en behörighet
Obligatoriska fält: händelsetid med tidszon, testkonto, åtgärd, resultat
Önskad lagringstid: 24 månader
Motivering: internt godkänd utredningsperiod
Bekräftad omfattning: återstår att klargöra före beställning och pilot
Anslutning och sökmetod: återstår att bekräfta för denna egen källa
Test: godkänd rolländring på ett särskilt testkonto
Återställning: återställ den ursprungliga rollen och kontrollera ändringen
Ansvariga team: applikationsteamet tillsammans med teamet för säkerhetsdrift

24 månader är här ett internt krav, inte en generell lagstadgad tidsfrist eller en produktstandard. Det överstiger den beskrivna standardlagringen, så en lämplig förlängning måste bekräftas före godkännande. Konton och händelser ersätts med de egna godkända testuppgifterna. Produktionsbehörigheter ändras inte för detta test.

Godkänn datainläsning och lagring separat

För piloten dokumenterar man utgångsläget och när datainläsningen börjar. Befintliga loggflöden behålls tills den nya källan har godkänts. Därefter skapar man en ofarlig, godkänd händelse som tillhör den planerade händelsekategorin. I exemplet ändras testkontots roll och återställs sedan till det dokumenterade ursprungsvärdet.

Efter den förväntade bearbetningstiden kontrollerar man följande via den sök- eller analysmetod som har bekräftats för källan:

Finns exakt testhändelsen i rätt tenantmiljö?
Stämmer källsystem, händelsetid, åtgärd och resultat med underlaget från källan?
Är de nödvändiga fälten mappade på ett begripligt sätt, i stället för att bara finnas som oanvändbar råtext?
Går det att följa ytterligare förväntade händelser under pilotperioden?

En nyfunnen post visar att datainläsningen fungerar för testet, inte att data redan har lagrats i flera år. För att godkänna lagringstiden jämför man också den bekräftade omfattningen med den faktiska inställningen eller en bekräftelse för den aktuella tenantmiljön. Befintliga historiska data kontrolleras med ett avgränsat tidsfönster; den äldsta hittade posten och kända luckor dokumenteras. För en ny källa utan historik dokumenterar man att långtidslagringen ännu inte har kunnat bevisas genom förfluten tid och planerar senare kontroller.

Kontrollen av datainläsningen förutsätter inget säkerhetslarm. En vanlig revisionshändelse kan behövas som datapost utan att leda till en incident. Data Collection och Live Discover förklarar befintliga XDR-frågor; det ger däremot ingen universell fråga för en ny egen källa.

Avgränsa fel och återställ ändringar säkert

Om tillägget eller en funktion saknas kontrollerar man först tenantmiljön, den faktiska statusen för Fusion-uppgraderingen och tilläggets bekräftade omfattning. Man skapar inte en andra integration på chans och ändrar ingen skyddspolicy för endpoints för att lösa en misstänkt licensbrist.

Om aktuella händelser saknas jämför man först underlaget från källan med starten för datainläsningen, händelsekategorin, autentiseringen, formatet och den överenskomna bearbetningsfördröjningen. Om poster finns men är oanvändbara kontrolleras fältmappning och tidsreferenser. Om bara äldre händelser saknas undersöker man separat starten för datainläsningen, dataluckor, faktisk lagringstid och sökningens tidsfönster. En senare förlängning av lagringstiden är ingen garanterad lösning för data som redan saknas.

Innan lagringstiden förkortas eller integrationen avvecklas klargör man med de ansvariga vilka data som fortfarande behövs och hur de kan säkras, i den mån det stöds och krävs. Man får inte anta att en senare återgång till det gamla värdet återskapar förlorad historik. Att ta bort en integration bevisar inte heller att redan inlästa data har raderats.

Om piloten misslyckas återställer man endast den dokumenterade ändringen i pilotkällan enligt dess bekräftade återställningsmetod. Delade inloggningsuppgifter, collectors och andra källor lämnas orörda. Därefter kontrollerar man det återställda källtillståndet och det gamla loggflöde som fortfarande behövs. Radering av data och uppsägning av tillägget klargörs separat med partnern eller de ansvariga; artikeln utlovar ingen universell knapp för detta.

Inför överlämning till drift måste källinventering, bekräftad omfattning, pilotunderlag, kvarstående historiska luckor, ansvar vid avbrott och granskningsdatum finnas. Om dataformat, sökmetod eller lagringstid för en nödvändig källa fortfarande är oklara är källan ännu inte godkänd. För eskalering räcker till en början tenantkoppling, tidsfönster, händelsekategori och rensade felunderlag; hemligheter och onödiga personuppgifter i råformat hör inte hemma i ärendet.