Sophos SIEM: välj transport och konfigurera HTTP Ingest

HTTP Ingest tar emot loggmeddelanden via en HTTPS-endpoint från Sophos. Källan måste kunna skicka HTTP POST till en webhook eller HTTP-endpoint med autentisering via Bearer-token. Det kräver en Sophos Next-Gen SIEM-prenumeration; en befintlig XDR-licens räcker inte.

Tre uppgifter hålls isär: välj transport, anslut källan och kontrollera faktiska händelser. En skapad anslutning bevisar inte korrekt normalisering eller detektion. Läs därför SIEM-grunderna och licenskontrollen före piloten.

Vilken transport passar källan?

Custom är avsett för källor utan lämplig Sophos-optimerad integration. Kontrollera först produktintegrationen och dess faktiska händelsekategorier i Marketplace. Ett välkänt leverantörsnamn innebär inte stöd för alla loggtyper.

Det finns sex alternativ:

• HTTP Ingest: direkt HTTPS POST med Bearer, utan egen molninfrastruktur att driva.
• Customer-Managed S3: loggar i en bucket i det egna AWS-kontot, vidarebefordrade med den levererade Lambda/CloudFormation-konfigurationen.
• S3 Ingest – Sophos-Managed (with token): Sophos-hanterat mål med ägarskapskontroll som leverantören kräver.
• S3 Ingest – Sophos-Managed (without token): samma ägarmodell utan kontrollen.
• Azure Event Hubs: händelseström i en åtkomlig hubb.
• Azure Storage Account: loggfiler i Blob Storage, vidarebefordrade av en Azure Function.

S3-guiden skiljer tre bucketalternativ åt. Azure-guiden separerar Event Hubs från Storage/Function. En syslog-enhet kan i stället behöva en XDR Data Collector; dess IP-adress ersätter inte HTTP Ingest-endpointen.

Förbered pilot och inloggningsuppgifter

Dokumentera tenant, SIEM-rättighet, källa, loggkategori och ansvarig. Allmän integrationskonfiguration kräver en lämplig Admin- eller Super Admin-roll samt åtkomst till källans exportinställningar. Källdokumentationen måste förklara URL, Bearer, format och överföringsbeteende. Ingen universell JSON-struktur förutsätts här.

Välj en godkänd testkälla och en ofarlig identifierbar händelse. Anteckna källtid med tidszon, testidentifierare och förväntade fält. Behåll befintliga loggvägar tills piloten godkänts; extra vidarebefordran får inte skapa oavsiktliga dubbletter eller otillåten personuppgiftsöverföring.

Integration Key och URL visas bara en gång. Förbered godkänd hemlighetslagring innan anslutningen skapas. Nycklar hör inte hemma i skärmbilder, ärenden, offentliga kodlager eller testkommandon som sparas i skalhistoriken. Dokumentera ägare och kontrollerad rotation. Integration Credential Manager stöder vissa typer och är ingen universell lagring för alla inläsningsnycklar.

Skapa HTTP Ingest i Sophos Fusion

1. Öppna Security Operations > Integrations > Marketplace > Custom.
2. Välj Set Up under HTTP Ingest.
3. Ange ett unikt namn, exempelvis Verksamhetsapp-Test-HTTP, och Done. Namnet är valfritt men bör identifiera källa och miljö.
4. Spara omedelbart Integration Key och URL i den avsedda lagringen. De visas inte igen. Saknas säker kopia pausas källans anslutning tills stödd ersättningsmetod klarlagts; senare återhämtning utlovas inte.
5. Konfigurera källans dokumenterade HTTPS-export med exakt dessa värden. Kontrollera Bearer, format och eventuella återförsök/buffring enligt källguiden. Använd ingen påhittad payload eller mall från ett annat API.
6. Hitta anslutningen under Configured integrations på Custom-sidan, skicka testhändelsen och kontrollera inläsningen separat.

En egen syntetisk källa med fullständig parsermall och sökfrågor beskrivs i det praktiska HTTP-/parserexemplet. Där skiljs förväntade resultat uttryckligen från det praktiska tenanttest som fortfarande återstår.

Godkänn transport, normalisering och analys

En Custom Integration ger först transport till XDR. Stödda loggtyper använder befintlig normalisering; egna eller okända format kan hamna i generic. Parsermodellen i SIEM-guiden förklarar varför en egen parser och rätt obligatoriska fält kan behövas.

Öppna Security Operations > Integrations > Configured Data Sources för godkännandet och välj den egna källan. I källinformationen visar Advanced Search en förberedd sökning för källans sensor-ID under de senaste 24 timmarna. Begränsa tidsfönstret till testtillfället och jämför tenant, källidentifierare, händelsetid, åtgärd och nödvändiga fält med den skickade händelsen. Godkänn integrationer förklarar ingången och Data Lake Search hur sökningen avgränsas ytterligare.

Grönt visar anslutning, inte fullständiga data eller korrekt schema. Generisk råtext som hittas bevisar inte att önskad detector kan använda den. Uteblivet resultat i enkel sökning utesluter inte generic-data.

Godkänn först när transport, användbar fältmappning och önskad sökning kan visas var för sig. Testa detektion endast om lämplig stödd logik är avsedd för källan. En vanlig gransknings- eller inloggningshändelse behöver inte utlösa larm.

Felsökning och kontrollerad avveckling

Vid saknade data kontrolleras först att källan verkligen skickat, använder rätt endpoint och använder nyckeln som avsedd Bearer-uppgift. Därefter källfel, nätverk, tidsintervall och status. HTTP-framgång ersätter inte händelsebevis. Felmappade data undersöks via format/parser i stället för att förebyggande skapa en andra anslutning.

Pausa genom källans dokumenterade exportmetod. Klargör beroenden, historiska bevis och lagringskrav före avveckling. Stoppa bara denna väg och kontrollera den gamla som fortfarande behövs. Radering av integration, återkallande av nyckel och radering av historik är skilda åtgärder utan utlovad universell knapp. Vid förlust eller kompromettering klarläggs stödd ersättning/återkallelse med Sophos; improvisera ingen oprövad rotation.