“Det var bättre förr” brukar man ju säga. Det stämmer även när det gäller IT-säkerhet.
Kanske inte bättre men enklare. För några år sedan hade vi en tydlig perimeter som skyddades av vår on-prem brandvägg.
Men med mer digitalisering, nyttjande av SaaS och IaaS samt på senare år ett kraftigt ökat distansarbete så har vi inte längre en tydlig perimeter att förhålla oss till.
Idag behöver vi hantera komplexa miljöer med många olika lösningar som tillsammans skapar en dynamisk och delvis okänd attackyta. Vi rullar ut diverse olika säkerhetslösningar för att försöka skydda vår miljö, men hur vet vi att de gör det vi tror?
Tidigare har man gjort sårbarhetsskanningar, men detta har blivit ohållbart eftersom antalet sårbarheter är så många att det inte går att överblicka. De flesta sårbarheter går dessutom inte att utnyttja för att komma över data eller ta sig vidare. Därför har man börjat att se på miljön ur ett riskbaserat perspektiv för att kunna gallra och sortera samt prioritera sina sårbarheter.
(Klicka på bilden för att få den större)
Lite större företag har även tagit hjälp av penetrations-testare, förenklat en “snäll hacker” som försöker ta sig in och förbi alla skyddsmekanismer. Men detta är både dyrt och tidskrävande vilket leder till att de inte kan göras oftare än 1-2 gånger per år. Dessutom är det svårt att få till enhetliga tester.
Tänk om man kunde automatisera detta?
Det är precis det man har gjort med ASV (Automatisk Säkerhets Validering), en lösning som med en lagom dos av AI/ML beter sig som en angripare hade gjort och letar sårbarheter som ensamma eller i kombination med andra leder till framsteg.
Detta innebär många fördelar:
- Repeterbarhet, eftersom den mänskliga faktorn eliminerats.
- Minskad kostnad, ett automatiserat system jobbar outtröttligt utan att det kostar per timme.
- Mer frekventa tester, istället för 1-2 gånger per år kan man nu få ett mått på sin risk, och möjlighet att åtgärda densamma, månadsvis, veckovis eller ännu tätare.
(Klicka på bilden för att få den större)
Men inte nog med att verktyget hjälper oss att identifiera risker, vi får dessutom hjälp med att både prioritera och åtgärda dem. Detta innebär ännu lägre kostnad eftersom man inte behöver köpa in eller anställa den kompetensen.
(Klicka på bilden för att få den större)
Så hur jobbar man rent praktiskt med ASV?
Det vanligaste är att man börjar med att testa sin interna miljö.
Först brukar man köra en Black-box, vilket är en helt icke-autentiserad körning som kan identifiera de allvarligaste bristerna.
Två exempel på attacker som inte har tillgång till några konton eller utnyttjar en enda CVE, vilket innebär att en traditionell sårbarhetsskanning inte kan upptäcka detta, och inga patchar existerar då det handlar om felaktig/osäker konfiguration som i det första fallet möjliggör sniffing samt relay-attacker. I det andra fallet är attack-vektorn lite mer komplex och innefattar en osäker certifikat-server med mera (attack-vektorn är känd under namnet Petit Potam).
(Klicka på bilderna för att få dem större)
Därefter körs en Gray-box där man ger verktyget till gång till ett konto (lokalt eller AD-konto) Detta är kanske det mest realistiska scenariot, att en angripare på olika sätt fått tillgång till en användares uppgifter eller i värsta fall etablerat någon form av fjärrstyrning av en användares maskin.
“Angripare bryter sig inte in, de loggar in.” Kan låta som en klyscha, men det är den verklighet vi måste förhålla oss till. Inom Zero-trust talar man om “Assume breach” som ett förhållningssätt för att kunna säkra upp sin miljö. Om inte annat för att kunna vara förberedda på en framtida attack.
Avslutningsvis
ASV testar inte bara hur motståndskraftig miljön är utan minst lika viktigt visar det om du kan se allt som pågår i miljön. Verktyget loggar allt den gör i nätverket och denna logg kan sedan korreleras med vad man ser i andra loggar (EDR, SIEM, SOC mm)
Ofta ser vi att man har säkerhetslösningar på plats, men de stoppar inte attacker för att de varit felaktigt konfigurerade. Vi har till och med sett kunder som betalat dyra pengar för en SOC-tjänst, men ingen på SOC:en har märkt att det pågått rekognosering och attacker i nätverket (förvisso etiska och icke-förstörande)
Så, för att svara på den inledande frågan, “Vem behöver Säkerhetsvalidering?” Så blir svaret “Alla som har möjlighet till det”.
De gamla metoderna räcker helt enkelt inte till längre.
Vi behöver även förändra hur vi ser på säkerhet och börja tänka samt agera mer riskbaserat.
/Johan Hillström
