Här går jag igenom hur Dan Practice tränar den operativa delen av säkerhetsarbete: att hitta rätt konfiguration, genomföra förändringen i rätt ordning och verifiera resultatet i ett verklighetsnära arbetsflöde.
Varför detta spelar roll
Dan Practice fokuserar på gapet mellan konceptuell förståelse och operativ förmåga. Att veta vilken kontroll som behövs är inte samma sak som att kunna hitta rätt administrationsyta, förstå beroenden och genomföra förändringen säkert.
Teknisk modell
Träningen modellerar längre portal- och CLI-flöden: observation → lokalisera konfiguration → pre-check → change → verify → rollback. Dan Entra ID Practice är den första implementationen.
Administrativa arbetsflöden
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.
Beroenden och konsekvensanalys
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.
Manuell förändring, verifiering och rollback
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
- Läs finding och identifiera vilken teknisk kontroll den gäller.
- Lokalisera rätt portal, policy, objekt eller CLI-kontext.
- Kontrollera scope och beroenden.
- Genomför stegen i rätt ordning.
- Verifiera med logg, policyresultat eller test.
- Beskriv rollback innan förändringen räknas som klar.
Konkret exempel
Jag använder gärna en enkel change-plan innan ett flöde automatiseras:
PRE-CHECK
- nuvarande värde
- berörda objekt
- beroenden
CHANGE
- minsta avgränsade förändring
VERIFY
- förväntat nytt tillstånd
- positivt och negativt test
ROLLBACK
- exakt återgångsväg
När detta fungerar manuellt blir det betydligt lättare att automatisera samma process med säkra parametrar, logging och begränsad behörighet.
Vad jag vill kunna verifiera
Målet är inte att memorera klickvägar. Man ska förstå varför stegen görs och vilket resultat som bevisar att säkerhetskontrollen fungerar.
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 träna UI utan säkerhetsprincip.
- Att hoppa över pre-check.
- Att anta att Save betyder lyckad remediation.
- Att sakna test av legitim användning efteråt.
Koppling till Dan Practice
Dan Practice använder frågan som operativ träning. Fokus ligger på de faktiska stegen mellan finding och verifierad förändring: rätt administrationsyta, scope, beroenden, change, verify och rollback.
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 Practice – från konceptuell förståelse till operativ säkerhetsförmåga 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.
Format och distribution
Dan Practice utvecklas som en körbar, paketerad Linux-applikation för lokal träning. Tanken är att operativa arbetsflöden ska kunna tränas reproducerbart utan att användaren först behöver bygga utvecklingsmiljön manuellt.
Utvalda stabila builds planeras att kunna laddas ned från itsec.nu. Källkod och arkitektur kan vid behov visas för potentiella arbetsgivare, kollegor eller andra tekniska granskare. Jag använder begreppet open source först när en faktisk open-source-licens och publik kodrelease finns.