Här går jag igenom CISA Malcolm ur ett praktiskt network security monitoring-perspektiv och tittar på hur PCAP, Zeek, Suricata, Arkime och OpenSearch kan användas tillsammans i analysen.
Varför detta spelar roll
CISA Malcolm visar hur flera open source-komponenter kan kombineras till en praktisk plattform för network traffic analysis. Den accepterar bland annat PCAP, Zeek-loggar och Suricata-alerts och gör data sökbar i Arkime och OpenSearch Dashboards.
Teknisk modell
Arkime hanterar PCAP/sessioner, Zeek skapar rik nätverksmetadata, Suricata ger IDS/threat detection och OpenSearch Dashboards används för sökning och visualisering. Malcolm normaliserar och berikar data mellan dessa komponenter.
PCAP, Zeek-loggar och Suricata-alerts som indata
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.
Arkime, OpenSearch Dashboards, Zeek och Suricata i samma analyskedja
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.
Normalisering, enrichment, sökning, visualisering och PCAP-baserad undersökning
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
- Bestäm om källan är live sensor, PCAP eller färdiga loggar.
- Kontrollera tidsperiod, sensor/asset och tagging.
- Börja med översikt och pivota sedan till session/event.
- Använd Arkime när paket/session är central.
- Använd OpenSearch Dashboards när aggregering och korrelation är central.
- Spara query/filter som gör analysen reproducerbar.
Konkret exempel
Ett praktiskt Malcolm-flöde kan börja i en översiktsdashboard där en ovanlig destination identifieras. Därifrån kan man begränsa tidsfönstret, filtrera på source.ip, destination.ip eller network.protocol och sedan pivota vidare till Arkime för sessions- eller PCAP-nära analys.
Det viktiga är att behålla samma frågeställning genom verktygen: vilken kommunikation skedde, när skedde den och vilken ytterligare evidens finns? Malcolm blir då ett sätt att röra sig mellan aggregerad visualisering och låg nivå utan att tappa kontext.
Vad jag vill kunna verifiera
Malcolm blir särskilt användbart när samma nätverksflöde kan undersökas från flera perspektiv. Jag vill kunna gå från en dashboard till sessionen och, när full PCAP finns, tillbaka till paketnivå.
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
- Att se en dashboard som färdig analys.
- Att spara all PCAP utan retentionplan.
- Att blanda sensorproblem med frånvaro av trafik.
- Att anpassa core-komponenter i onödan när externa integrationer räcker.
Varför Malcolm är relevant för mina egna projekt
Malcolm är ett bra exempel på att flera specialiserade open source-komponenter kan bli starkare tillsammans. Dan-Lite Malc är inte ett försök att påstå att Malcolm behövs ersättas; jag använder principen som inspiration för en mer fokuserad, resurssnål analystyta och endpointkorrelation.
Open source och kommersiella plattformar
Jag tycker att jämförelsen behöver vara kravbaserad. En öppen stack kan täcka många av samma operativa behov som kommersiella NDR/IDS/EDR/SIEM-plattformar och kan vara starkare i transparens, integrationsfrihet och möjlighet att bygga egna dashboards. Kommersiella produkter kan samtidigt ha tydliga fördelar i support, SLA, färdiga integrationer, threat intelligence och paketerad drift. Jag vill därför kunna motivera arkitekturen utifrån behov, inte utifrån licensmodell.
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
CISA Malcolm – så fungerar en modern open source-plattform för nätverkstrafikanalys 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.