Här går jag igenom den tekniska idén bakom Dan-Lite Malc och hur jag vill förena nätverksdata, endpointdata, PCAP och kontrollerad respons i en gemensam analystyta. Jag skiljer samtidigt tydligt mellan planerad arkitektur och sådant som redan är implementerat och verifierat.
Varför detta spelar roll
Dan-Lite Malc är ett R&D-projekt där jag undersöker hur flera öppna säkerhetskomponenter kan ge en gemensam analystyta utan att ersätta de specialiserade verktygen under. Eftersom projektet är under utveckling skiljer jag tydligt mellan planerad arkitektur och funktioner som redan är implementerade och verifierade.
Teknisk modell
Nätverksdelen kan använda PCAP, Zeek, Suricata och Arkime-liknande analys. Endpointdelen kan hämta agentstatus och inventory från Wazuh. OPNsense och Node-RED kan vara kontrollerade response- och orkestreringspunkter där det är lämpligt.
Resurssnål SOC/NDR-idé för små och medelstora miljöer
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.
En gemensam dashboard ovanpå öppna komponenter snarare än ett nytt monolitiskt SIEM
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.
Planerad arkitektur och verifierad implementation hålls tydligt isär
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
- Samla eller importera nätverks- och endpointdata utan att ändra originalkällan.
- Normalisera identiteter för host, IP, agent och session.
- Bygg analystvyer som svarar på konkreta frågor.
- Pivota från finding till rå evidens.
- Skapa åtgärdsförslag med approval och allow-list.
- Skriv tillbaka verifieringsresultat och receipt till incidenthistoriken.
Konkret exempel
Ett tänkt analystflöde i Dan-Lite Malc är:
Finding: ny listening port
↓
Wazuh agent → process → Windows service
↓
Zeek/Arkime → nätverkssessioner från samma host
↓
Suricata → eventuell IDS-träff
↓
Analystbeslut → godkänd response → verify → receipt
Det är den här typen av pivot jag vill prioritera framför ett stort antal fristående diagram. Dashboardens uppgift är att minska vägen mellan fråga och evidens.
Vad jag vill kunna verifiera
Jag vill att dashboarden ska vara en arbetsyta, inte en alternativ sanningskälla. Varje finding bör kunna spåras till PCAP, logg, agentdata eller annan originalkälla.
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 blanda ihop planerad arkitektur med funktion som redan är implementerad och verifierad.
- Att göra en ny agent när Wazuh redan löser agenthantering.
- Att bygga en monolit istället för integrationslager.
- Att blanda offensiva Cyber Range-kontroller med framtida Dan-Lite Malc Real.
Koppling till Dan-Lite Malc
Det här är en del av den arkitektur jag vill samla i Dan-Lite Malc. Jag beskriver den som R&D eftersom en planerad dashboard inte ska presenteras som en färdig produkt. Målet är en analystyta där varje finding kan pivota tillbaka till ursprunglig network- eller endpointevidens.
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
Dan-Lite Malc – varför jag vill samla nätverk, EDR och incidenthantering i ett lättare gränssnitt 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.
Projektformat och status
Dan-Lite Malc ska skiljas från de färdiga Dan Labs och från Dan Cyber Range. Det är ett separat Security Platform R&D-spår där jag utvecklar arkitektur och prototyper för en framtida paketerad Linuxplattform. Jag beskriver därför inte planerade dashboard- eller responsefunktioner som färdig produkt förrän de är implementerade och verifierade.
Målet är att en framtida stabil version ska kunna distribueras lokalt och i stor utsträckning offline, med dokumenterade integrationsgränser mot exempelvis Wazuh, Zeek, Suricata, Arkime och OPNsense. Källkod och arkitektur kan också användas som underlag för teknisk diskussion med arbetsgivare och kollegor.