00:00 Christian Ja, goddag. Velkommen til endnu et afsnit i How to Get There From Here. Mit navn er Christian.

00:07 Martin Og jeg hedder Martin. Og dagens emne, det er Conditional Access. Conditional Access, svært ord. Hvor vi har, er det syv anbefalede policies? Ja.

00:23 Martin Jeg er så din medkontrollør i den her session i jagten på kære for os billetter. Skal jeg ikke lægge ud med den første? Jo. Policy, vi har talt om, og det er jo egentlig noget så fundamentalt som at kræve MFA for alle brugere i virksomheden eller i miljøet. Og den er med, fordi det er et krav, det kan du stille via Conditional Access.

00:52 Martin Men det kræver alligevel lidt omtanke, når man gør det, så man ikke generer brugerne med MFA-prompt i tid og udtid. Så ja, helt fundamentalt. Kræv noget MFA. Find ud af, hvordan din serieregel skal strikkes sammen for at gøre det bedst muligt med taget brugernes oplevelse i mændte. Det var regel nummer et. Og du vil sige noget om nummer to?

01:17 Christian Regel nummer to, ja, den er jo egentlig også fundamental. Det er blokering af legacy og fatigering. Og legacy-protokollerne er jo kendt for ikke at kunne klare MFA, så ved at blokere den, så højner du ret hurtigt din sikkerhed.

01:33 Christian Det er jo igen, ligesom du taler om med MFA for alle brugere, så er det ikke noget, du måske nødvendigvis bare lige kan kan slå til, uden at der er noget, der kan måske gå galt. Microsoft har jo været meget flinke til at lave en workbook i en, så man kan se omkring legacy-authentikeringen. Bliver det overhovedet brugt? Og hvis det gør, hvor er det så henne? Og hvem er det, der gør det? Og så har man nemmere ved at kunne navigere til den her regel her og få den slået til. Og det er jo så også sagt, at Microsoft har jo også en Microsoft Managed en, man kan benytte sig af, hvis man vil det. Og nu kommer vi til et af vores mere favoritter, som vi jo også har talt om i det. Næsten i hvert fald.

02:17 Martin Ja, min kærlighed, eller vores kærlighed, i hvert fald i sidste afslutning af vores podcast, var det vores kærlighed at kræve eller require fishing-resistant MFA for at forade mine roller.

02:28 Martin Og det handler jo egentlig om at være beskydt i de her privilegerede roller som Intune Admin og User Admin, Global Admin osv. Med den bedste form for MFA, vi har til rådighed, og det er jo så Phishing Resistance. Det er jo enten via Parsky eller noget andet, der ikke kan phishes af de ondsendede.

02:46 Martin Ja, og det talte vi om i sidste afsnit. Så har vi, det var regel nummer tre. Vores regel nummer fire på listen, det er jo så at kræve compliant og eller hybrid joint device. Og hybrid joint selvfølgelig, hvis man stadig har on-prem AD til rådighed. Og det skal bare jo…

03:06 Martin en rigtig god base for at tilgå ved virksomhedsressourcer, hvis det er et krav, især on-premium-avd, at det kræver nogle bestemte permissions at få sådan et device i hånden, at den er domain-joint og indvidere så også compliant i Intune og Intra. Så hvis man kan stille det krav, så udelukker man jo, at man kan tilgå company resources fra andet end det, altså private devices og så videre.

03:32 Christian Der var noget, jeg tænkte på i forhold til det med compliant devices. Man har jo selv lov til at definere sin compliant rule. Skal man ikke det i interviewen?

03:42 Martin Jo, det gør man. Der er noget, der hedder compliance policies i interviewen, hvor du kan stille diverse krav til, at devices er compliant. Det er alt muligt. Det er måske nærmest en situation for sig selv. Man kan stille krav om, at der er aktive interviews, Der er en aktiv Windows Firewall, og en dag også. Kan du gøre noget med PowerShell, så du kan stille hvad som helst af krav for, at devices er compliant? Jeg tror, det bliver et godt afdelt en dag. Det bliver en episode for sig selv.

04:11 Martin Hvornår betaler vi noget til nummer fem?

04:14 Christian Ja, det er security, altså MFA-registrering, security information registration. Og det er en butik, som gør, at den kun tillader dine brugere at sætte MFA op fra trusted locations. Og det kan jo være…

04:31 Christian Jeg vil nok ikke gå så langt og sige, at det skal være for bestemt et lande af det. Man tillader det nok mere i forhold til, at det skal være på ens firmakontor. Det er kun her, man tillader at sætte MFA op. Og netop for at begrænse, at hvis en ondsindet får kompromiseret en bruger, så kan de ikke begynde at sætte MFA op for fremmede lande af, for eksempel. Så du begrænser den del af det og gør dig mere sikker i forhold til, hvordan din brugeres MFA faktisk er sat op.

04:59 Christian Og den næste, vi har på vores liste, er jo lidt nede i den samme boldgade også. Det er jo en, vi har talt om også nogle gange. Den her med blokering af unknown, unsupported devices. Hvis man er en virksomhed, som for eksempel kun benytter sig af Windows-devices,

05:17 Christian Og iOS devices, jamen så er det måske meget naturligt og ret hurtigt at blokere forbrugen af Android og MacOS devices, og andre unknown systems. Jeg ved ikke, om du vil sætte nogle flere ord på den også, Martin?

05:31 Martin Ja, og jeg tror, at den regel eller policy er med, fordi man reelt set kan konfigurere platform i Condition Access, og så egentlig Vælge alle platforme, inklusive unknown, unsupported, og så kan man lave en exclusion liste til det, det vil sige, at man exkluder de platforme, man bruger, aktive brugere i ens miljø, som iOS og Windows. Og det handler så om, at man blokerer alt andet, end de to, eller de platforme, man i virkeligheden benytter. Og det er jo en smart måde at bygge på sikkerheden. Man kan jo selvfølgelig begrænse, hvilke platforme man tillader, at kan invokale ind i en tyvende i første omgang. Men man kan også begrænse simpelthen, at de får lov at authenticate videre til company resources via conditional access. Ja, så den sidste på listen, der er en filte, der er nummer syv, det er så Require MFA for Risky Sign-ins, og så er vi over i det produkt, der hedder Identity Protection, som så også kræver en ændret P2, det vil sige, hvis man ikke har E5, så er man nødt til at investere nogle penge for at få den her licens.

06:41 Martin Men det er meget smart, fordi via maskinlønning, så smager

06:47 Martin Motoren bl.a. på atypiske rejser. Det vil sige, at hvis man er lukket ind i København, og fem minutter efter er lukket ind i London, så siger den her maskinløgning, at der er noget galt. Det er simpelthen umuligt at lave den rejse på så kort tid. Lad os lige få brugeren til at bekræfte, at vedkommende er. den de påstår at være. Så kan man simpelthen rejse et krav om MFA på baggrund af det risk event, der sker der. Man kan mere med identity protection, men det er en af de smarte ting, som det blandt andet tillader.

07:19 Christian Jeg tror ikke, jeg har set den endnu fra København til Aarhus, for eksempel, blive triggert den vej igennem. Det skal være lidt større rejser. Større afstand.

07:30 Martin Ja, og det handler jo om, at hvis der sidder en bruger i København, der er lige ude at rejse, og har fået så lært maskinen bagved, at vedkommende opholder sig mest i København, og logger typisk ind i København, hvis vedkommende så lige pludselig…

07:44 Martin logger ind i et andet land, det kan jo også trigger et risk event, at hey, lave noget MFA, eller skifte lige dit password, eller blokere egentlig brugeren. Der er flere elementer i den del af identity protection. Ja.

08:01 Martin Var vi igennem alle reglerne der?

08:04 Christian Ja, det var alle syv. Og med det, så er der jo en masse værktøjer, Microsoft stiller til rådighed for. Hvis man ikke allerede er i gang med Conditional Access, så er der jo templatesne, som Microsoft har lavet. Det er jo en relativt ny ting, at der er kommet Conditional Access templates, som man slipper for at skulle sidde og konfigurere. Det giver sig stilling til, at man får noget ud af boksen, så at sige. Man nemt kan trykke det bløje på. Der har blevet den samme holdning som mig. Prøv lige i starten at read report only hedder det, ikke read only. Read only Friday. Og en af de ting, jeg er meget glad for i Intra også, at de workbooks, der er stillet til rådighed, som er der giver indsigt i ens miljø, blandt andet omkring legacy-offentlikeringen,

08:59 Christian Ja, det tror jeg var det for dagens afsnit, Martin. Jeg ved ikke, om du har mere at tilføje?

09:05 Martin Nej, vi kan lige opsummere, hvad de syv regler var for noget en gang til. Jeg tror, vi startede med at kræve MFA fra alle brugere.

09:15 Martin Gør det med omtanke, hvis man ikke har det i forvejen. Men på en eller anden måde kræve, at der er med fag i alt, hvad brugeren tilgår. Det skal selvfølgelig ikke være, hver gang brugeren starter Outlook eller Word eller noget andet. Det vil vi irritere brugeren. Nummer to, Block Legacy Authentication, som du får igennem. Tre, vores kærlighed til Phishing Resistance, den der med fag for admin-roller. Det kan du jo godt udvide til de almindelige brugere også, hvis du er student.

09:40 Christian Ja.

09:43 Martin Og så kræver compliant og hybrid joint device. Det er også en rigtig god idé at have det som en baseline-sikkerhed for at tilgå firmaressourcer.

09:53 Martin Og så var der, hvor kan du få lov at registrere MFA henad, opsætte MFA. Det er selvfølgelig svært at kræve MFA for at opsætte MFA’en, hvis man ikke har sat det op i forvejen, men der er nogle muligheder for så at begrænse det til, som du sagde, nogle bestemte lokationer, nogle bestemte public IP-adresser, så det kun kan ske, når man er på kontoret. Ja.

10:15 Martin Og dermed blokere unknown, unsupported device platforms, det vil sige, hvis du kommer fra Kali Linux og har noget ondsind og kørende der, så bliver du blokeret i din authentication. Vi har den type regel, og i sidste ende fortalte vi om identity protection, hvis du laver atypiske rejser eller noget andet, hvor machine learning siger, at der er noget galt med det her user sign-in. Skal vi blokere det? Skal vi prompte på noget MFA? Eller skal vi simpelthen bede brugeren om at skifte sit passaport i det flow? Jeg tror det, ja. Var det ikke de syv regler, vi lige kunne komme på? Der er mange flere end det, tror jeg.

10:54 Martin Der var jo flere gode idéer. Ja, det er en god start at starte med dem. Hvis man ikke har dem, så kan man jo starte med det. Og starte småt. Starte med pilotgrupper. Starte med, som du sagde, report only, og så monitorere brugernes sig indlagt i ændrede efterhånden, som man bevæger sig frem. Jeg tror, at man har en god start og får en god basis for lidt bedre sikkerhed.

11:18 Christian og måske også de her på falderævet, der er jo faktisk også sådan en gap-analyzer-workbook, der viser, hvor man har hullet i sin conditional access inden sig selv. Hvis man føler, man er i et godt sted lige nu, så kan det jo være værd lige at tjekke den ud. Det tager jo ikke meget mere end fem minutter at navigere ind til den, og så se, er der noget, man bør gøre, som man ikke allerede gør i forvejen. Ja. Det var det sidste, jeg egentlig havde tilføj til det. Det var det, togkontrollerende havde af

11:45 Martin at byde på det, vi havde. Vi ses i næste afsnit. Hej.