Hoppa till innehållet
Avanet
Logga in

Sophos SIEM: verifiera HTTP Ingest och parser i ett exempel

Exemplet kopplar en syntetisk JSON-källa till HTTP Ingest, en Custom Parser för Auth-schemat och en riktad sökning. Det visar därmed vägen mellan de separata anvisningarna för HTTP Ingest och Custom Parsers. Exemplet rapporterar enbart fiktiva laboratorieinloggningar; det gör ingen verklig användarinloggning och kontrollerar inga autentiseringsuppgifter.

Förbered labbet och definiera framgång

Det krävs en testtenant med Next-Gen-SIEM-Subscription, en auktoriserad Admin- eller Super-Admin-roll och en godkänd dator med Python 3 och HTTPS-åtkomst till tilldelad Ingest-endpoint. SIEM-planeringen förklarar licens- och lagringsgränser. En befintlig XDR-åtkomst räcker inte ensam för Custom-transport och Custom Parsers.

Labbformatet är avsiktligt snävt: ett JSON-meddelande per POST, fältformatet nedan och den fasta källan avanet-lab-source. HTTP-hjälpen beskriver HTTPS-POST med Bearer-token men fastställer där ingen generell svarskropp, statuskod eller payloadstruktur för alla källor. Kontrollera före sändtestet den faktiskt tilldelade endpointen och dess aktuella krav. Om den konkreta leveransen kräver en annan Body-struktur anpassas denna först enligt tillhörande dokumentation; mallen är ingen universell Ingest-API-specifikation.

Dokumentera före start tenant, ansvarig person, integrationsnamn, parsernamn och testtid. Det förväntade resultatet består av tre separata underlag:

  1. Den godkända laboratoriekällan har skickat exakt avsett meddelande.
  2. Parsern mappar de fiktiva källvärdena korrekt till Auth-schemat.
  3. Meddelandet går att hitta i rätt tenant med rätt tid, källa och testidentifierare.

HTTP-framgång, grön Connector eller syntaktiskt giltigt skript räcker inte ensamt för verifieringen. Varken detektion eller MDR-hantering av denna labbhändelse förväntas.

Testformat och fullständig parsermall

Laboratoriekällan använder denna enskilda JSON-rad:

{"product":"avanet-siem-lab","schema_version":1,"event_type":"logon","sensor_id":"avanet-lab-source","user":"pilot-user","src_ip":"192.0.2.25","session_id":"avanet-lab-20261029T101500Z","time":"2026-10-29T10:15:00Z","result":"success"}

192.0.2.25 är en dokumentationsadress. pilot-user är ingen tenantanvändare. session_id identifierar denna fiktiva labbkörning, inte en verklig inloggningssession. Vid det senare sändtestet genererar skriptet aktuell UTC-tid och en ny identifierare; den fasta exempeltiden används bara i parsereditorn.

Skapa under Security Operations > Integrations > Custom Parsers > Add Custom Parser en ny parser med namnet AVANET_LAB_JSON_AUTH. Välj Standalone, källformat JSON och målschema Auth. Skriv inte över eller utöka befintliga globala parsers. Följande fullständiga mall beskriver enbart det visade labbformatet:

!SCHEMA=scwx.auth
!CONFIRMWITH=PATTERN
!CONFIRMSTRING=^\{"product":"avanet-siem-lab","schema_version":1,"event_type":"logon","sensor_id":"avanet-lab-source","user":"[^"]+","src_ip":"[^"]+","session_id":"[^"]+","time":"[^"]+","result":"(success|failure)"\}$
!TRIMALLOFF
!SAMPLE={"product":"avanet-siem-lab","schema_version":1,"event_type":"logon","sensor_id":"avanet-lab-source","user":"pilot-user","src_ip":"192.0.2.25","session_id":"avanet-lab-20261029T101500Z","time":"2026-10-29T10:15:00Z","result":"success"}

json = JSON(originalData$)
sensorType$ = "AVANET_SIEM_LAB"
sensorId$ = json["$.sensor_id"]
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]
sessionId$ = json["$.session_id"]
authSystem$ = json["$.product"]
eventTimeUsec$ = DATETIME(json["$.time"], "2006-01-02T15:04:05Z07:00")
authCategory$ = 10
action$ = IF json["$.result"] == "failure" THEN 8 ELSE 1
actionResult$ = IF json["$.result"] == "success" THEN 10 ELSE 20

Confirm String är avsiktligt begränsad till exakt denna kompakta serialisering med fast fältordning. Snyggt indragen JSON eller en annan ordning matchar inte. För en verklig källa utformas igenkänningsmönstret på nytt utifrån representativa originalmeddelanden; en bred sökning enbart efter ordet ”logon” är ingen likvärdig ersättning.

För detta labb mappas de använda Auth-fälten och deras fasta enumvärden på följande sätt:

RåvärdeParserfältFörväntad normalisering
sensor_idsensorId$sensor_id
usersourceUserName$source_user_name
src_ipsourceAddress$source_address
session_idsessionId$session_id
UTC-timeeventTimeUsec$event_time_usec
LaboratorieinloggningauthCategory$ = 10ACCOUNT_LOGON
successaction$ = 1, actionResult$ = 10LOGON, SUCCESS
failureaction$ = 8, actionResult$ = 20FAILURE, FAILED

Siffrorna är schema-enums, inga fritt valda allvarlighetsgrader. Go-tidsformatmallen i DATETIME() behåller UTC-tecknet respektive en ISO-8601-zonoffset. Råvärde och normaliserad mikrosekundtid jämförs i editorn. Mallen sätter varken tenantId$ eller resourceId$ själv; ersätt inte dessa med fritt påhittade tenant- eller händelseidentifierare.

Kontrollera i parsereditorn utan aktivering

Klistra in den enskilda exempelraden i Sample Message. Öppna Parse Message och sedan Source Destination Mapping. Jämför schema, användare, adress, tid, resultat och extractor path mot tabellen. En varning om en annan parser måste redas ut före aktivering.

Lägg därefter in flera enskilda meddelanden som motprov:

  • Ändra result till failure: förväntat är action=8 och action_result=20.
  • Ändra product till other-lab: meddelandet får inte tilldelas denna parser.
  • Ändra result till unknown eller ta bort user: meddelandet får inte normaliseras som en lyckad inloggning; den snäva Confirm String ska utesluta det.
  • Ange ett ogiltigt tidsvärde: ett fel eller avsaknad av korrekt tid stoppar godkännandet. Acceptera inte importtiden som skenbar framgång.

Run Test kontrollerar schema och Extractor Paths för alla inlagda Samples. Sophos rekommenderar olika Samples och 12–15 testkörningar; kontrollera då den parserväg som faktiskt används. Parse Message ger Parsed Source Message och Source Destination Mapping för kontroll av enskilda meddelanden. Ett test sparar inte parsern; Save och Deploy är separata steg. Att spara är inget testbevis. Låt en ny parser först förbli avstängd. För redan aktiva parsers får ändringar effekt direkt vid sparandet; därför använder labbet en egen ny parser. Den allmänna parserrunbooken beskriver aktivering och återgång.

Förbered ett enskilt HTTP-sändsteg

Efter godkännande i testtenanten skapas en separat integration AVANET-LAB-HTTP under Security Operations > Integrations > Marketplace > Custom > HTTP Ingest > Set Up. För omedelbart över Integration Key och URL till godkänd Secret Store; Sophos visar dem bara en gång. Ställ ännu inte om någon befintlig källa.

Python-exemplet nedan skickar exakt ett meddelande som det själv skapar. URL och nyckel efterfrågas dolt och lagras inte som kommandoargument, skalvariabel eller del av källtexten. Normal TLS-certifikatkontroll förblir påslagen; HTTP-omdirigeringar följs inte så att Bearer-nyckeln inte hamnar på ett annat mål. Skriptet innehåller avsiktligt inga automatiska återförsök, eftersom dessa utan bekräftat beteende kan skapa dubbla händelser.

import datetime
import getpass
import json
import urllib.error
import urllib.parse
import urllib.request
import uuid

class NoRedirect(urllib.request.HTTPRedirectHandler):
    def redirect_request(self, req, fp, code, msg, headers, newurl):
        return None

url = getpass.getpass("Integration URL: ").strip()
key = getpass.getpass("Integration Key: ")
parsed = urllib.parse.urlsplit(url)
if parsed.scheme != "https" or not parsed.hostname or parsed.username or parsed.password or parsed.fragment:
    raise SystemExit("Nur die freigegebene HTTPS-URL ohne eingebettete Zugangsdaten verwenden.")

now = datetime.datetime.now(datetime.timezone.utc)
time_text = now.strftime("%Y-%m-%dT%H:%M:%SZ")
run_id = "avanet-lab-" + now.strftime("%Y%m%dT%H%M%SZ") + "-" + uuid.uuid4().hex[:8]
event = {
    "product": "avanet-siem-lab",
    "schema_version": 1,
    "event_type": "logon",
    "sensor_id": "avanet-lab-source",
    "user": "pilot-user",
    "src_ip": "192.0.2.25",
    "session_id": run_id,
    "time": time_text,
    "result": "success",
}
request = urllib.request.Request(
    url,
    data=json.dumps(event, separators=(",", ":")).encode("utf-8"),
    headers={"Authorization": "Bearer " + key, "Content-Type": "application/json"},
    method="POST",
)
print("Testkennung:", run_id, "UTC:", time_text)
try:
    with urllib.request.build_opener(NoRedirect()).open(request, timeout=15) as response:
        print("HTTP-Status:", response.status)
except urllib.error.HTTPError as error:
    print("HTTP-Fehler:", error.code, "— nicht automatisch erneut senden.")
except urllib.error.URLError:
    print("Verbindungs- oder TLS-Fehler — URL, Vertrauenskette und Netzwerkweg prüfen.")

Spara koden i en lokal labbfil utan hemliga värden och starta med Python 3. URL:en måste komma exakt från godkänd labbintegration; koden verifierar inte ägarskap till en godtycklig HTTPS-värd. Ta inte med nyckel eller URL i offentliga konsolinspelningar eller ärenden. Skriptet skapar inga kund-, lösenords- eller produktionssessionsdata.

Inte heller efter ett HTTP-svar påstås lyckad Ingest. Vid timeout är det oklart om servern redan har tagit emot meddelandet. Sök därför efter noterad testidentifierare före en ny överföring. Vid 401/403 klargörs tilldelade autentiseringsuppgifter och godkännandestatus utan att behörigheter utökas på chans. Vid 4xx på grund av Body-format kontrolleras konkret Ingest-specifikation i stället för att prova nya JSON-omslag godtyckligt.

Sök råmeddelande och normaliserad händelse

Kontrollera först transporten separat. Sök under Data Lake Search > Query Editor i ett snävt tidsfönster efter den testidentifierare som skrevs ut:

FROM generic WHERE original_data CONTAINS 'avanet-lab-20261029T101500Z' earliest=-1h

Ersätt exempelvärdet med den identifierare som faktiskt skrevs ut. I Original Data ska produkt, källidentifierare, användare, tid och resultat motsvara den skickade raden. sensor_id i den generiska händelsen kan bestämmas av insamlingsvägen. Ett integrationsvisningsnamn är därför inte automatiskt rätt sökidentifierare. Använd först det faktiskt befintliga värdet om sökningen dessutom ska filtrera på sensor_id.

Aktivera den nya labbparsern medvetet efter godkända editortester och skicka ett nytt testmeddelande. Förutsätt inte att redan inlästa rådata därmed normaliseras om i efterhand. Sök den förväntade Auth-händelsen med definierade labbfält:

FROM auth WHERE sensor_id = 'avanet-lab-source' AND session_id = 'avanet-lab-20261029T101500Z' earliest=-1h

Ersätt identifieraren även här. Kontrollera Normalized Data i träffen: source_user_name=pilot-user, source_address=192.0.2.25, källans tid, action=1, auth_category=10 och action_result=10, eller motsvarande enumnamn som visas i gränssnittet. extractor path måste tillhöra labbparsern. Kontrollera varje fält separat i sökresultatet.

För det kontrollerade misslyckandeförsöket ändras enbart result till failure i den egna generatorn, en ny testidentifierare skapas och meddelandet skickas exakt en gång igen. Schemat ska då visa action=8 och action_result=20. Ett ytterligare lyckat normaliseringsresultat för unknown eller en främmande produktidentifierare vore däremot ett skäl att avbryta.

Avgränsa fel och avveckla labbet

Inget råmeddelande: Kontrollera sändtid och testidentifierare, transportsvar, rätt tenant, tidsfönster och källa. Behandla inte avsaknad av sökträffar som ensamt bevis för transportfel; generisk råsökning behöver utökade parametrar och åtkomst till original_data är tidsbegränsad.

Råmeddelande finns, ingen Auth-träff: Kontrollera parserstatus, exakt serialisering, Confirm String, schema och parserväg. Gör inte produktionsparsers bredare för att på något sätt fånga labbhändelsen.

Auth-träff med fel resultat eller tid: Jämför källa och mappning separat. Inaktivera parsern och korrigera den sparade skriptversionen; fyll inte ut med påhittade standardvärden.

Stoppa den egna sändaren efter verifiering och stäng bara av den nyss skapade labbparsern med Disable. Därmed upphör dess extra normalisering; generiska data och redan lagrade händelser ska inte betraktas som borttagna. Ta bort labbintegrationen först när ersättnings-/återkallelsevägen för dess nyckel är klarlagd och godkänd. Avvecklingen får inte ändra en delad integration eller annan datakälla.

Fortsatt förvaltning följer SIEM-arbetsflödet: dokumentera källformat och parserversion tillsammans, verifiera på nytt efter ändringar och planera retention samt larmhantering separat.