Här går jag igenom området ur ett praktiskt analys- och nätverkssäkerhetsperspektiv. Fokus ligger på vilken rådata man kan använda, hur observationer korreleras och hur en teknisk slutsats kan verifieras.
Varför detta spelar roll
PCAP är rå nätverksevidens. Där loggar ofta är en tolkning av vad ett verktyg såg kan paket ge möjlighet att gå tillbaka till den faktiska kommunikationen, så långt fångsten och eventuell kryptering tillåter.
Teknisk modell
Jag skiljer mellan capture, retention, processing och investigation. Man behöver först veta var trafiken fångas och vilken tidsperiod som finns innan analysverktyget kan ge ett meningsfullt svar.
Capture-metod och tidsfönster
Det här avgränsar vilken tillgång, datakälla eller konfiguration som ska undersökas först. Med ett tydligt scope blir det lättare att skilja relevant evidens från närliggande brus.
Filter och sessionsanalys
Nästa fråga är vilken påverkan observationen har på miljön och vilka beroenden som berörs. Innan en förändring görs behöver man förstå blast radius och vilken ytterligare evidens som krävs.
Korrelation mot loggar och incidenttidslinje
Här kopplas observationen till ett konkret tekniskt arbetsmoment. Beroende på miljö kan det innebära en portal, query, API, CLI eller loggkälla, men steget ska vara reproducerbart och möjligt att granska.
Praktiskt arbetsflöde
- Definiera capture point och tidsfönster.
- Kontrollera att snaplen, rotation och tidsstämplar är rimliga.
- Filtrera först på fem-tupel, protokoll eller känd tidslinje.
- Bygg sessioner och jämför med Zeek/Suricata/endpointloggar.
- Bevara originalfilen och arbeta på kopia när evidensvärde är viktigt.
- Dokumentera vilka filter och antaganden som användes.
Konkret exempel
Vid nätverksanalys försöker jag börja med så få antaganden som möjligt. Ett avgränsat capture-filter eller display-filter gör det lättare att förstå vad som faktiskt finns i datan.
ip.addr == 10.20.30.40 && tcp.port == 443
I terminalen kan samma princip användas för en begränsad kontroll:
tcpdump -nn -r capture.pcap 'host 10.20.30.40 and tcp port 443'
Därefter kan man jämföra sessionens tid, riktning och endpoints med Zeek-, Suricata- eller endpointdata. Jag använder helst filter som går att dokumentera och återköra.
Vad jag vill kunna verifiera
En PCAP-analys ska gå att reproducera med samma filter och tidsgränser. Jag vill kunna peka från en slutsats tillbaka till paket eller sessioner, inte bara till en skärmbild.
Man kan använda följande kontrollfrågor:
- Vilken rådata eller konfiguration stödjer slutsatsen?
- Vilket resultat förväntas efter en förändring?
- Finns ett negativt test som visar att en förbjuden väg verkligen är stängd?
- Kan man återgå säkert om förändringen ger en oväntad sidoeffekt?
Vanliga fallgropar
- Fångst på fel nätverksplats.
- För kort retention för incidentens tidslinje.
- Tidszoner som inte stämmer mellan källor.
- Att anta att frånvaro i PCAP betyder att händelsen inte skedde.
Koppling till yrkesrollen
För mig är värdet i ämnet att det går att koppla till ett verkligt analyst- eller engineeringflöde. Man behöver kunna förklara varför kontrollen finns, vad som ska mätas och hur resultatet verifieras.
Frågor jag tar med till en verklig miljö
När jag lämnar labbet och tänker på en riktig verksamhet försöker jag alltid ställa några kontrollfrågor innan samma metod används skarpt:
- Vilken tillgång eller affärsprocess påverkas om kontrollen fungerar fel?
- Vilken person eller funktion äger systemet och kan bekräfta legitimt beteende?
- Vilken telemetry finns redan, och vilken datakälla saknas för att slutsatsen ska bli tillräckligt stark?
- Vilken del kan testas i begränsad scope innan förändringen breddas?
- Hur dokumenteras expected result, efterkontroll och rollback så att nästa tekniker kan förstå vad som gjordes?
Sammanfattning
SPAN, TAP och PCAP – hur man samlar trafik för analys handlar för mig ytterst om att göra säkerhetsarbetet begripligt och verifierbart. Man får ett bättre resultat när analysten kan gå från observation till evidens, från evidens till avgränsad åtgärd och från åtgärd till ett kontrollerat eftertest.