Anslut molnets flödesloggar till Sophos XDR och SIEM

Molnets flödesloggar beskriver nätverksanslutningar, inte paketens fullständiga innehåll. Sophos XDR kan ta emot dem från AWS VPC Flow Logs, Azure Network Watcher, Google Cloud Platform (GCP) och Oracle Cloud Infrastructure (OCI). Vägen beror på källan: S3 och Lambda för AWS, Azure Storage och en Function för Network Watcher, Pub/Sub för GCP samt Streaming för OCI.

Netflow-telemetri från dessa integrationer kräver Sophos Next-Gen SIEM. GCP och OCI levererar även andra scheman genom samma integrationer. Det gör inte alla molnbaserade gransknings- och säkerhetsdata beroende av SIEM. Kontrollera först kategorier, tenant, Fusion-uppgradering och licensrättigheter. SIEM och retentionsplanering förklarar det kommersiella omfånget.

Dessa direkta molnanslutningar skiljer sig från en syslogcollector som körs i molnet. För den vägen gäller XDR-collectorns runbook.

Före den första molnändringen

Det krävs rätt produktruta för måltenanten under Security Operations > Integrations > Marketplace, godkända molnbehörigheter för berörda resurser och ett team som ansvarar för löpande kostnader, nycklar och datakvalitet. Kontrollera tillgänglighet och fält i den egna tenanten. Ersätt inte en saknad ruta med en integration med liknande namn.

Dokumentera molnkonto eller prenumeration, region, önskade loggkategorier, målintegration och insamlingsstart för varje källa. Begränsa rättigheterna till den avsedda vägen. Administratörsbehörighet vid driftsättning motiverar inte permanent användning av ett personligt administratörskonto som integrationsidentitet. Lambda, Storage och Pub/Sub kan medföra separata molnkostnader.

Grön integrationsstatus bekräftar kommunikation, inte fullständig inhämtning. Godkännandet kräver en tillåten, ofarlig testhändelse med källbevis och tid, följd av motsvarande normaliserade post. Integrationsguiden förklarar rättigheter, flöde och skillnaden mot responsåtgärder.

AWS VPC Flow Logs via en egen S3-bucket

AWS VPC Flow Logs hämtas från en egen Amazon S3-bucket. Sophos tillhandahåller en CloudFormation-mall som skapar en vidarebefordrande Lambda-funktion. Det krävs ett AWS-konto, en bucket med flödesloggar och rättigheter att skapa nödvändiga Lambda-, CloudFormation- och IAM-resurser.

Öppna AWS VPC Flow Logs i Sophos Marketplace. Läs S3-informationen under Configured integrations > Add new, välj Next, ange ett identifierbart namn och välj Done. Hämta mallen som genereras efter provisioneringen och förvara den med begränsad åtkomst.
Rikta den avsedda VPC-exporten mot denna bucket i AWS. Loggmålet måste vara Amazon S3. Använd bara AWS standardformat; eget format kan försämra normalisering och detektion.
Öppna CloudFormation > Create stack i samma AWS-region som loggbucketen, ladda upp mallen och välj ett stacknamn utan blanksteg. Ställ IntegrationType på awsvpcflow. Ange bucketnamnet, inte en URL eller S3-URI, i NotificationBucket. Om SNS medvetet används i stället för S3-notifieringar anges dess ARN i SNSNotificationarn. Kontrollera övriga parametrar mot den planerade vägen.
Granska och godkänn skapandet av IAM-resurser, skapa stacken och vänta på CREATE_COMPLETE. En separat bucket för mallen behöver inte göras offentlig.
Öppna funktionen som skapats av stacken under Lambda. Lägg till loggbucketen som S3-källa via Function overview > Add Trigger. Välj Event Type: All Object Create Events. Prefix ska enbart innehålla det faktiska loggprefixet; lämna tomt om inget prefix används. Lämna Suffix tomt. Kontrollera kostnaderna och lägg till triggern.
Skapa ett lämpligt, ofarligt nätverksflöde inom valt VPC-område. Verifiera först loggposten i bucketen och jämför sedan tidsperiod och anslutningsuppgifter i Sophos-schemat netflow.

Det obligatoriska standardformatet är:

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

Om data saknas kontrolleras först exportmål, nya objekt, region och triggerprefix. Mallen sätter Reserved Concurrency till 5 som standard; det är ingen dimensioneringsgaranti. Bedöm belastning och CloudWatch-mätvärden. Rate Exceeded kan avse en AWS-kvot för samtidiga körningar. Upprepad återskapning av Sophos-integrationen löser inte den gränsen.

Azure Network Watcher via Storage och Azure Function

Network Watcher skriver NSG Flow Logs eller VNet Flow Logs till ett Azure Storage Account. Nya NSG Flow Logs kan inte längre skapas. Planera VNet Flow Logs för nya källor. Befintliga NSG Flow Logs kan anslutas tills de ersätts; Microsoft avvecklar funktionen den 30 september 2027. Planera migreringen till VNet Flow Logs före detta datum. Typerna kräver separata Sophos-integrationer, eftersom de använder olika Blob-containrar eller Data Source Keys.

Det krävs aktiv Azure-prenumeration, Storage Account med Blob-container och aktiverade flödesloggar samt en Azure Function-tjänsteplan som stöds. Dokumenterade val är Basic med B1, B2 eller B3, Dynamic med Y1 och vissa Premium-koder. Isolated stöds inte. Välj en Premium-kod ur den aktuella listan, inte utifrån ett liknande plannamn.

Låt Network Watcher skriva VNet Flow Logs för en ny källa till avsett Storage Account; använd befintliga NSG Flow Logs endast som en övergång fram till migreringen. Anteckna konto- och containernamn och kontrollera att nya objekt faktiskt kommer in.
Öppna Microsoft Azure Network Watcher - Azure Storage Account i Sophos Marketplace och skapa integrationen under Azure Storage Accounts > Set Up.
Kopiera Storage Account Name exakt. Function App Name är ett eget beskrivande namn, exempelvis NSGFlowLogsForwarder, inte ett fast produktvärde. Ange Data Source Key som insights-logs-networksecuritygroupflowevent för NSG eller insights-logs-flowlogflowevent för VNet.
Välj Azure Function Service Plan Type, motsvarande Service Plan Code och Num Workers. Standard är en worker. För Basic B2/B3 dokumenteras högst tre; generalisera inte gränsen till andra planer.
Välj Done för att skapa och hämta AzureFunction.json. Läs in filen i Azure via Deploy a custom template > Build your own template in the editor. Kontrollera Resource Group och parametrar, välj sedan Review + Create och Create.
Storage Account och Function får finnas under olika Subscription IDs eller Resource Groups. Ange då uttryckligen Storage Account Subscription ID och Storage Account Resource Group för den verkliga källan.
Verifiera efter driftsättning ett väntat flöde i rätt container och sedan som netflow i Sophos. Godkänn varje integration separat om båda loggtyperna används.

Om Function är driftsatt men data saknas kontrolleras container, Data Source Key, Subscription-/Resource-Group-koppling och plan. En andra integration av samma ström kan skapa dubletter och är ingen generell reparation.

GCP via Pub/Sub

GCP levererar cloudaudit, thirdpartyalert och, med SIEM, netflow. Källor som stöds är Cloud Audit Logs, Security Command Center Findings, VPC Flow Logs och GKE Dataplane V2. Inkludera bara medvetet valda kategorier.

Skapa ett topic under Pub/Sub > Topics i rätt GCP-projekt och en prenumeration under Subscriptions. Sätt Acknowledgement deadline till 300 sekunder.
Skapa under Logging > Log router > Create Sink en sink med detta Cloud Pub/Sub topic som mål. Begränsa inclusion filters till nödvändiga loggkällor. Organisations- och mapploggar kräver en lämplig aggregerad sink; en projektsink omfattar dem inte automatiskt.
Skapa ett separat tjänstekonto. Ge dess ID rollen Pub/Sub Subscriber via Add Principal på Pub/Sub-prenumerationen.
Skapa också en anpassad roll med monitoring.timeSeries.list och tilldela den till kontot. Ett konto som redan används av Sophos XDR kan återanvändas om även denna nödvändiga behörighet är godkänd.
Skapa en JSON-nyckel och förvara den säkert. Öppna GCP > Configured integrations > Add new i Marketplace, ange namn, Project ID och Pub/Sub-Subscription ID, och ladda upp rätt JSON med Upload Key File.
Aktivera verkligen valda källor: Data Access-auditloggar kräver uttryckligt tjänsteval under IAM & Admin > Audit Logs. SCC-findings använder motsvarande Pub/Sub-export. Aktivera VPC Flow Logs på subnätsnivå; sampling begränsar deras bevisvärde jämfört med fullständig paketfångst.
GKE Dataplane V2 måste väljas när klustret skapas. Kontrollera därefter Network Policy Logging och sinkfiltret. Ersätt inte ett befintligt kluster oplanerat bara för en loggningspilot.
Skapa en passande händelse per kategori och kontrollera källbevis, Pub/Sub-väg och normaliserat schema separat.

Vid nyckelrotation skapas först den nya JSON-nyckeln och den befintliga Sophos-integrationen uppdateras. I API Query Log visar secrets cache invalidated. Integration was updated. Restarting. uppdateringen. Ta bort den gamla GCP-nyckeln först efter att dataflödet verifierats igen. En lyckad filuppladdning räcker inte.

OCI via Streaming

OCI levererar cloudaudit, http, nids och, med SIEM, netflow. Det krävs en OCI-stream, önskade loggar och en service connector. Integrationsidentiteten behöver stream-pull för läsning; generella administratörsrättigheter krävs inte för löpande hämtning.

Förbered en särskild loggningsanvändare och godkänd grupp-/compartmentstruktur. Ge endast nödvändig läsåtkomst till rätt stream.
Välj rätt Stream Pool under OCI Streams > Create Stream. Anteckna Stream Pool OCID; det kan inte ersättas med ett godtyckligt stream- eller compartment-ID.
Styr godkända audit-, flow-, load-balancer-, WAF- eller firewallloggar till streamen via Connector Hub. Kontrollera före Sophos att connectorn faktiskt levererar till rätt Streaming-mål. Ett annat mål fyller inte automatiskt denna stream.
Öppna OCI > Configured integrations > Add new i Marketplace. Ange Name, separat Username, dess Auth token, Stream Pool ID, Tenant Name, streamens Topic Name samt Region.
För nästlade compartments är Tenant Name tenancy-namnet utan compartmentkedjan. För federerade användare i det dokumenterade OracleIdentityCloudService-fallet används exempelvis acme/OracleIdentityCloudService, där acme står för den egna tenancyn. Blanda inte ihop fallen.
Välj Done och verifiera en lämplig händelse i OCI, Streaming-vägen och förväntat Sophos-schema. Ett cloud-audit-event testar inte en ytterligare netflow-ström.

Kontrollera först Stream Pool, streamnamn, region, token och stream-pull om inhämtningen misslyckas. Saknas bara en kategori granskas källval och connectorrouting innan hela integrationen skapas om.

Datakvalitet och kontrollerad avveckling

Dokumentera källa, insamlingsstart, period, normaliserat schema och ett reproducerbart exempel per kategori. Jämför tid och tidszon med källbeviset. Ett vanligt flöde eller en auditpost behöver inte ge en detection eller ett MDR-case. En grön anslutning eller hittad post bevisar inte heller flera års retention.

Kartlägg väg och gemensamma resurser före avveckling. Stoppa bara godkänd export, sink, trigger eller connector; radera inte en gemensam bucket, topic, Storage Account eller stream urskillningslöst. När inga nya poster kommer in tas berörd Sophos-konfiguration och exklusivt använda nycklar eller resurser bort enligt change- och retentionsbeslut. Borttagning av anslutningen bevisar inte att historisk telemetri raderats.

Behåll tidigare nödvändiga loggvägar vid en misslyckad pilot. Rollback återställer den dokumenterade nya routing- eller exportändringen och verifierar utfallet. Det gör inte automatiskt redan överförda data, molnkostnader eller förlorade händelser ogjorda.