Här går jag igenom hur det aktuella Dan-labbet används för att träna säkerhetsanalys från finding och evidens till manuell åtgärd, verifiering och rollback.
Varför detta spelar roll
Dan Labs är pedagogiska säkerhetssystem som gör det möjligt att träna ett stort antal findings och analystbeslut utan krav på en full produktionsbackend. Deras styrka ligger i struktur, variation och återkoppling.
Teknisk modell
Ett scenario går från säkerhetsprincip och evidens till manual fix, preview, remediation, verification och rollback. Labben visar även hur en framtida Real-version bör automatisera säkert via API/protokoll.
Finding och evidens
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.
Manual fix och change-plan
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.
Verify/rollback och realistiska scenarier
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
- Analysera finding och evidens.
- Förklara risk och säkerhetsprincip.
- Ta fram realistisk manual fix.
- Gör pre-change safety checks.
- Verifiera förväntat resultat.
- Beskriv rollback och framtida säker automation.
Konkret exempel
En första KQL-sökning bör vara enkel och lätt att verifiera. För en identitetsfråga kan man exempelvis börja med ett snävt tidsfönster och därefter lägga på fler villkor:
SigninLogs
| where TimeGenerated > ago(24h)
| project TimeGenerated, UserPrincipalName, IPAddress, AppDisplayName, ResultType
| order by TimeGenerated desc
Poängen är inte att queryn i sig är avancerad. Den skapar ett kontrollerbart utgångsläge. Därefter kan man pivota på identitet, IP, applikation och resultatkod och kontrollera om samma tidslinje stöds av andra datakällor.
Vad jag vill kunna verifiera
Jag testar labben både tekniskt och pedagogiskt: svarsalternativ ska vara unika, finding-logik konsekvent och remediationen ska motsvara problemet.
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ör många nästan identiska frågor.
- Remediation utan konsekvensanalys.
- UI som antyder riktig backend när den är simulerad.
- Ingen skillnad mellan labb och verklig range.
Koppling till Dan Labs
I Dan Labs modellerar jag samma säkerhetslogik i många varierade scenarier. Labbet ska ge snabb träning i analys och beslut, medan Dan Practice och Dan Cyber Range tar andra delar av realism.
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 Sentinel SOC Lab – incidentanalys, KQL och åtgärdsflöden 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.
Källor och vidare läsning
Format och distribution
Detta Dan Lab är inte bara artikel- eller quizmaterial utan en körbar, paketerad Linux-applikation som används lokalt i min träningsmiljö. Dan Labs har testats på Linuxmiljöer som Parrot OS och Bazzite och är byggda för reproducerbar träning av många säkerhetsscenarier.
Jag planerar att göra utvalda stabila builds tillgängliga för nedladdning från itsec.nu. För teknisk granskning kan relevanta delar av källkod, arkitektur och dokumentation visas eller delas med potentiella arbetsgivare och kollegor även innan en publik open-source-release finns.