Zoals besproken in aflevering 3 van onze podcast, in verband met incidenten die we het afgelopen jaar gezien hebben, was het duidelijk dat bad actors minder inbreken maar meer inloggen met een compromised account.

Beluister hier de podcast over de incidenten die ons het afgelopen jaar het meest zijn bijgebleven:

Attackers proberen via die weg een hoger type (privileged account) te bemachtigen om dan bepaalde admin taken te kunnen uitvoeren. Zoals in podcast 3 besproken: deleten van backups, encrypteren van vmdk’s, domain take over, etc zoals hieronder beschreven:

Wat duidelijk maakt dat we meer moeten inzetten op detectie en protectie op het identity domein en er alles aan moeten doen om hier extra lagen van security te implementeren.

Hiervoor heeft Microsoft een best practice beschreven die een 3 tier model heeft om zo “Zero Trust Principles on all accesss” af te dwingen met least privileged, assume Breach and explicit validation of trust te implementeren.

https://learn.microsoft.com/en-us/microsoft-identity-manager/pam/tier-model-for-partitioning-administrative-privileges

Dit model moet ervoor zorgen dat er voor iedere Tier een andere account gebruikt wordt om zo besmetting van één Tier naar de andere niet mogelijk te maken. Maar iets beschrijven en uitwerken op papier maakt het niet altijd gemakkelijk om dit ook daadwerkelijk te implementeren en brengt een aantal problemen met zich mee.

• Probleem 1: Geen inzicht in besmetting tussen de verschillende Tiers! 
• Probleem 2: Geen gemakkelijke manier om deze besmetting tussen verschillende Tiers tegen te gaan (virtual fencing)
• Probleem 3: privileged accounts (Tier 0-1) worden maar zeer weinig van de totale tijd gebruikt om taken uit te voeren, dus waarom moeten deze constant actief zijn? (JIT: Just In Time)

Waar er problemen zijn, zoeken wij natuurlijk naar oplossingen en zullen we de typische attack chain meer in detail bespreken en een mogelijke oplossing voorstellen

Probleem 1: Geen inzicht in besmetting tussen verschillende Tiers

Nu hebben veel bedrijven meestal een apart account voor Tier 2 en een gecombineerd account voor Tier 0-1. Het zou dus een verbetering zijn om ook deze Tier 0 en 1 te scheiden met dedicated accounts. Maar om inzichten te krijgen waar bepaalde accounts gebruikt worden beschikken ze momenteel niet over een tool, verder kunnen ze ook niet detecteren of deze Tier 0 of Tier 1 accounts mogelijk voor Tier 2 zaken worden gebruikt en daardoor Tier 2 besmetten met een Tier 0 of 1 account.

Dit zal ervoor zorgen dat een bad actor via een compromised Tier 2 account een Tier 0-1 (privileged account) kan bemachtigen en zo de zaken kan doen die we besproken hebben in onze podcast aflevering 3, namelijk toegang krijgen tot kritische applicaties, servers, data, etc.

Probleem 1: Geen inzicht in besmetting tussen de verschillende Tiers! Zoals hieronder voorgesteld.

Oplossing 1: Deze inzichten en een detectie capability kunnen we voor onze klanten beschikbaar maken via Silverfort tool (versie 5.2), zodat je kan zien welke account voor welke Tier gebruikt wordt en of er besmetting is van een bepaalde account naar andere Tiers!

Probleem 2: Besmetting tussen Tiers tegen gaan (virtual fencing)

Nu krijgen we alerts als deze accounts niet gebruikt worden waarvoor ze bestemd zijn en kunnen we zien waar welke account niet correct gebruikt wordt. Maar zou het ook niet beter zijn als voor deze accounts kunnen afdwingen dat deze enkel maar voor die bepaalde doeleinden gebruikt kunnen worden, zodat een vergetelheid of menselijke fout uitgesloten wordt? Wat ons bij het 2^de probleem brengt, namelijk:

Probleem 2: Geen gemakkelijke manier om deze besmetting tussen verschillende Tiers tegen te gaan (virtual fencing)

Oplossing 2: Ook hiervoor zal in versie 5.2 van Silverfort de mogelijkheid zijn om virtual fencing in te stellen en dus een policy aan te maken waar je duidelijk aangeeft waarvoor deze privileged accounts aangemaakt zijn en tot welke Tier deze behoren en dus enkel mogen gebruikt worden binnen deze Tier en niet de mogelijkheid hebben om naar een andere Tier te gaan en dus besmetting niet meer mogelijk is.

Probleem 3: Waarom zijn privileged accounts constant actief?

Nu we deze privileged accounts hebben kunnen segmenteren en kunnen beperken tot het speelveld waar ze nodig zijn, is er nog één extra stap die we kunnen nemen.

Eigenlijk gebruiken we bepaalde privileged account maar zeer zelden voor zeer bepaalde taken en zou het een enorme extra laag van security zijn dat we deze account enkel maar actief maken wanneer we deze nodig hebben (liefst nog via MFA) en ook maar voor een zeer beperkte tijd zodat ook de windows van attack zeer klein wordt. Wat ons bij probleem 3 brengt.

Probleem 3: privileged accounts (Tier 0-1) worden maar zeer weinig van de totale tijd gebruikt om taken uit te voeren, dus waarom moeten deze constant actief zijn? (JIT: Just In Time)

Oplossing 3: Ook hier zal er in versie 5.2 van Silverfort de mogelijkheid bestaan naast het virtual fencing om ook een JIT  feature te activeren, die ervoor zal zorgen dat deze privileged accounts by default disabled zijn in Active Directory en enkel op aanvraag (via MFA) enabled zullen worden voor een zeer beperkte tijd om de nodige taken uit te voeren en dan terug te disablen zodat misbruik van deze account niet mogelijk is buiten bovenstaande window.

Geïnteresseerd in meer informatie over Silverfort? Neem contact met ons op via info@jarviss.nl