MFA is de nieuwe standaard voor toegang tot Azure portals

Binnenkort is het zover, met een beheeraccount inloggen in Azure Portal werkt na 15 oktober alleen na versterkte authenticatie, inloggen met alleen een wachtwoord is dan niet meer mogelijk. MFA, “multi-factor authenticatie”, is de nieuwe standaard. Het voordeel van deze extra beveiligingseis is dat die, in tegenstelling tot een wachtwoord dat gekopieerd of gedeeld kan worden, een extra niet te kopiëren bewijs vraagt. Volgens Microsoft is met name de hausse aan phishingaanvallen een aanleiding om deze maatregel voor het hele Azure platform door te voeren. Gebruik van MFA verlaagt het risico op misbruik aanzienlijk, zeker wanneer gebruik gemaakt wordt van zogenaamd ‘phishing-resistant’ MFA methoden, bijvoorbeeld een USB-device, gezichtsherkenning of een digitaal certificaat. En dat moeten organisaties dus vóór 15 oktober hebben ingericht!

MFA: maatregel tegen grootste dreiging

Vanuit de optiek van security kunnen we deze stap alleen maar toejuichen, we willen immers zeker weten dat alleen iemand die toegang mag hebben, ook daadwerkelijk toegang kan krijgen. Gestolen inloggegevens, ‘credentials’, vormen al jaren de belangrijkste wijze waarop cyberaanvallers toegang krijgen tot gevoelige bedrijfsinformatie, zo blijkt uit het jaarlijks DBIR rapport. In de laatste versie van dat rapport staat dat in meer dan 50% van de gerapporteerde datalekken gestolen credentials en/of phishing een rol speelde. Dit roept om het inbouwen van extra zekerheid. En in de cloud is dat nog een graadje erger dan in een on-prem situatie: traditioneel moest een beheerder fysiek binnen een netwerk aanwezig zijn om toegang te kunnen krijgen en werden in die situatie soms whoop-whoop signalen verspreid om inlog door een beheerder te melden. In de cloud kan elke beheerder altijd overal vandaan als beheerder inloggen. En dat kan dus ook elke niet-beheerder. Die extra maatregelen zijn er niet voor niets.

Maar inrichten van MFA stelt ons wel voor problemen. Want voor welke accounts gaat dat gelden, wat zijn dan de beperkingen en hoe richten we dat in? In dit artikel belichten André Koot van SonicBee en Erik Remmelzwaal van Zolder deze vraagstukken vanuit zowel een organisatorisch als een technisch perspectief.

De verandering

De nieuwe maatregel richt zich op alle binnen Entra ID beheerde accounts, zowel van medewerkers als van beheerders, zowel persoonlijke als onpersoonlijke accounts. Dat eerste ligt voor de hand: we willen zekerheid over het inloggen door alle personen met hun persoonlijke account. Accounts mogen niet door derden overgenomen worden (bijvoorbeeld na een phishingaanval), want dat betekent identiteitendiefstal en vermoedelijk leidt dat tot security-incidenten en datalekken. en kennen de meeste gebruikers wel het principe van een extra handeling om in te loggen.

SMS als MFA-methode

Maar alhoewel MFA een flinke verbetering is, zijn ook hiervoor inmiddels geslaagde pogingen tot omzeilen van de maatregel aangetroffen. Zo wordt het gebruik van SMS als authenticatiemethode al een tijdje afgeraden, vanwege het feit dat SMS onversleuteld is en op verschillende manieren onderschept kan worden, alhoewel het door de relatieve gebruiksvriendelijkheid en platform-onafhankelijkheid toch nog vaak wordt gebruikt.

Authenticator Apps (TOTP)

Beter is het gebruik van een authenticator-app. Dat kan in beginsel elke app zijn die voldoet aan de open TOTP-standaard (TOTP = Time-based One Time Password), dus de Microsoft Authenticator app, Google Authenticator, Duo, maar ook open source apps zoals Authy. Maar ook daar hebben de boeven alweer wat op gevonden. Microsoft rapporteerde half augustus een toename van 111% in een jaar tijd van zogenaamde Token Replay aanvallen. In dergelijke aanvallen wordt de aangemelde sessie van een gebruiker, na MFA authenticatie, gekopieerd door de aanvaller. Dat kopiëren is mogelijk met behulp van malware op een computer, of als de aanvaller zich tussen de aanmelder en Microsoft weet te nestelen: een zogenaamde Adversary-in-te-Middle (AiTM) aanval.

Phishing Resistance

Wat overblijft zijn de zogenaamde ‘phishing-resistant’ authenticatiemethoden. Daaronder valt bijvoorbeeld het gebruik van biometrie via Windows Hello, waarbij een vingerafdruk of gezichtskenmerken worden gescand en gecontroleerd. Waar Microsoft zelf eigenlijk naar lijkt te hinten, is inzet van een FIDO2 component, denk met name aan de hardwarematige beveiligingssleutels zoals Yubikey USB devices. Het beheren van een fysiek authenticatiemiddel introduceert natuurlijk extra complexiteit waardoor het mogelijk niet voor elke gebruiker haalbaar is, maar de nieuwe MFA verplichting van Microsoft wordt gericht op beheertaken dus zou volstaan kunnen worden met een phishing-resistant MFA methode voor beheerders.

Wat is de impact en voor wie?

Tot zover niet heel spannend, het is een laagdrempelige maar waardevolle verbetering. Complexer wordt het voor niet-persoonsgebonden accounts. Dat zijn bijvoorbeeld systeemaccounts en service-accounts, maar ook het ‘break-glass’ noodaccount.

Laten we deze types eens doornemen:

Systeemaccounts zijn accounts zoals Administrator of root (op linux). Beheerders kunnen met dergelijke accounts inloggen en kunnen dan als Administrator of root beheertaken uitvoeren. Er zijn veel risico’s verbonden aan dergelijke accounts. Misschien wel het belangrijkste risico: het zijn anonieme accounts, waardoor je niet kunt weten welke natuurlijke persoon inlogt… In de regel mogen ze niet gebruikt worden voor dagelijkse beheertaken. Ze zouden dan ook uitsluitend via een enveloppenprocedure (dus het wachtwoord is opgeborgen in een fysieke kluis) of bij voorkeur via een Privileged Access Management oplossing beschikbaar gesteld mogen worden. In veel situaties wordt het account dan ook disabled om misbruik te voorkomen.

Service-accounts, ook wel service principals genoemd, zijn accounts waarmee niet ingelogd kan worden, het zijn bijvoorbeeld de accounts waarmee een webserver draait, of waarmee een robot process automation (RPA) oplossing geconfigureerde taken uitvoert. Belangrijkste beveiligingsmaatregel is dus het voorkomen dat met dergelijke accounts kan worden ingelogd!

Break-glass accounts. Noodaccounts. Dit zijn eigenlijk slapende accounts die in noodsituaties gebruikt zouden kunnen worden om beheerderstoegang te krijgen. En ook dit account is anoniem.

Dit onderscheid maakt het wel al makkelijker om de verbetering die Microsoft door gaat voeren te duiden: het gaat om systeemaccounts en break-glass accounts, want de service-accounts zijn (mits goed beheerd) geen risico. En als we praten over authenticatie, dan hebben we de uitdaging dat deze beide types accounts onpersoonlijk zijn, dus iets als biometrie is niet aan de orde.

MFA voor niet-persoonsgebonden accounts

Gelukkig bestaan er verschillende mogelijkheden om MFA voor niet-persoonsgebonden accounts mogelijk te maken. De belangrijkste is wel dat er gebruik gemaakt kan worden van een U2F-device, ofwel het eerder besproken phishing-resistant, FIDO2 compatible device: een Yubikey of een Solo-usb-token. Dit zijn devices die gekoppeld kunnen worden aan een account, dus ook aan een niet-persoonsgebonden account. Als met zo’n account wordt ingelogd, vindt een validatie van de rechtmatigheid plaats doordat wordt gecontroleerd of het USB-device geldig is. Ook zou gebruik kunnen worden gemaakt van een smartcard met daarop een digitaal certificaat, maar gebruik daarvan vereist toch wel enige kennis van Public Key Infrastructure (PKI) en is voor de meeste organisaties eigenlijk geen reële optie.

Fysieke beveiliging blijft relevant

Leuk en aardig, maar als een aanvaller die het wachtwoord al te pakken heeft gekregen, dat USB-device ook heeft, dan haalt het nog niet veel uit, toch? Correct. Om die reden is het noodzakelijk om die tokens op een veilige manier te beheren en bewaren, bijvoorbeeld in een fysieke kluis. Zo zou een proces moeten worden ontwikkeld om het token uit de kluis te halen, door bijvoorbeeld in een logboek te laten vastleggen wie het token wanneer en waarvoor nodig heeft, bijvoorbeeld om incident i3342 of change c76756 af te handelen. En denk na over die kluis: als er een kluis gebruikt wordt voor het bewaren van het FIDO2-token, let erop dat die kluis wel beschikbaar is als het account nodig is (in noodsituaties als het om het break-glass account gaat), dus ook buiten kantoortijden. Misschien moet je daarom in een tweede locatie wel een tweede kluis beschikbaar hebben.

Controleer periodiek de logging van de tenant op gebruik van de betreffende accounts.

Let vooral op de Global Admin autorisatie. Het Microsoft Privileged Identity Management systeem (PIM) kan helpen om het gebruik van die autorisatie te stroomlijnen, let er dan ook op dat niet teveel mensen toegang hebben tot die autorisatie.

Voorbereiden op 15 oktober

Op 15 oktober zet Microsoft de knop om. Wil je dan toegang krijgen tot bepaalde beheeronderdelen in de Microsoft365 dan zal de beheerder zich moeten authenticeren met MFA. Wil je op dat moment aanmelden met een account dat nog geen MFA heeft geactiveerd? Dan zul je gedwongen worden het te configureren. Natuurlijk kan het op dat moment verstorend werken voor de beheerwerkzaamheden, en is het beter om de configuratie voor de 15e oktober al klaar te hebben.

Ga daarom als volgt te werk:

Breng in kaart welke beheerders nog geen MFA methode geregistreerd hebben. Microsoft biedt hier enkele tools voor, maar je kunt ook Attic gebruiken (zie hieronder)
Activeer een (bij voorkeur phishing-resistant) MFA methode voor deze en andere beheerders

Conditional Access

Vervolgens kan in Entra ID Conditional Access alvast het beleid geactiveerd worden dat Microsoft op 15 oktober zal uitrollen. Door dit beleid in ‘monitoring’ mode te zetten, kan via de sign-in logs bekeken worden of er toch nog proberen met authenticatie ontstaan zonder dat deze direct tot blokkades leiden.

Voeg voor dit doel onder Conditional Access nieuwe policies toe op basis van sjablonen (templates) die Microsoft biedt. Bij het toevoegen van een nieuwe policy vanuit template, filter op All om alle suggesties van Microsoft te zien. Er zijn 3 templates die aansluiten bij dit verhaal, op volgorde van impact:

Titel	Toelichting
Require multi-factor authentication for Microsoft admin portals	Dit is 1 op 1 wat Microsoft op 15 oktober gaat activeren: wil je inloggen op een beheerportal van Microsoft, dan moet je op dat moment MFA gebruiken. Gebruik van andere Microsoft onderdelen (Outlook, Teams, enz) kan nog MFA-vrij zijn.
Require multi-factor authentication for admins	Dit gaat een stapje verder en vereist altijd MFA voor beheerders, ongeacht op welke app ze inloggen. Wel verstandig want als een kwaadwillende toegang krijgt tot de mailbox of onedrive van een beheerder dan geeft dat meestal een goudmijn aan informatie.
Require phishing-resitant multifactor authentication for admins	Dit gaat nog een stapje verder want dit stelt ook nog eisen aan het type MFA methode dat de admin mag gebruiken om te authenticeren. Toegestane MFA methode zijn dan: Windows Hello for Business, FIDO2 security key (bijv Yubikey) en Certificate-based authentication

Zo helpt Attic

Organisaties die hun Microsoft tenant beschermen met Attic Security (80 euro per maand, ongeacht aantal users), worden met verschillende checks geholpen bij het goed inrichten van MFA.

CKK-1327 – Verplicht MFA voor alle gebruikers (wel zo handig)
CHK-1328 – Verplicht MFA voor beheerders (gelijk aan 2e conditional access policy hierboven)
CHK-1137 – Toont welke beheerders nog geen MFA-methode geregistreerd hebben

Tevens zal Attic met een set aan checks het inrichten en bewaken van een Emergency Access (Break-Glass) account begeleiden.

In de periode naar 15 oktober zullen de checks verder worden uitgebreid of aangescherpt om mee te gaan in het nieuwe beleid van Microsoft en klanten zo goed mogelijk hierbij te assisteren.

Attic biedt 1-kliks oplossingen aan om de nodige configuratie in te schakelen. Vervolgens zal Attic doorlopend blijven controleren of de configuratie nog staat zoals gewenst of dat iemand een ongewenste wijziging heeft aangebracht.

Twee weken gratis testen: https://atticsecurity.com/try

Samenvatting

De maatregel die Microsoft invoert is een belangrijke om de kritieke accounts en autorisaties op een effectieve manier te beschermen. De maatregel is betrekkelijk laagdrempelig, maar de impact is hoog, want hiermee wordt phishing van dergelijke accounts zo goed als onmogelijk gemaakt. Maar daarvoor moeten wel enkele aanvullende maatregelen worden getroffen, zoals activeren van MFA, inzet van (bij voorkeur) een FIDO2 token, maar dat heeft dan weer wel de consequentie van beperkte, aanvullende beheermaatregelen.

Zorg ervoor dat de relevante MFA-instellingen vóór 15 oktober 2024 goed zijn ingesteld, want anders zijn de Azure portalen niet meer toegankelijk. Microsoft maakt het weliswaar mogelijk om uitstel te krijgen, maar dat is beslist geen best practice!