![[RSS]](https://tweakers.net/g/if/v2/icons/rss_small.png){kind=icon}
Let op: Tweakers stopt per 2023 met Tweakblogs. In
dit artikel
leggen we uit waarom we hiervoor hebben gekozen.
Microsoft Cloud Security (Lessons Learned)
De laatste tijd heb ik veel ervaring opgedaan met Azure Security en M365 Security. hier een aantal dingen die ik heb geleerd de afgelopen tijd, die de basis vormen van een goede Azure Security / M365 Security.
Conditional Access
Conditional Access is de basis van een veilige cloud omgeving, en daarmee kun je het ook enorm complex maken.
Zelf ben best gecharmeerd om naar persona's te kijken en op basis daarvan je Conditional Access te ontwerpen.
Daarnaast heeft Claus Jespersen, Principal Security Consultant bij Microsoft daar een enorm goed document over gepubliceerd. Zie dat document als basis inrichting van conditional access, daarnaast kun je natuurlijk op basis van je eigen requirements extra persona's toevoegen.
https://www.linkedin.com/...-6798870787546779648-huo4
Identity"
1.Zo min mogelijk admins met hoge privilige rollen (bijvoorbeeld Global Admin of Security Admin), Global Admin sowieso beperken tot noodaccounts an de rest allemaal toekennen via Azure Privliged Identiy Management. Het voordeel daarvan is dat een admin rol maar voor een x aantal uur toegekend en daarna niet meer actief is. En daarnaast kun je ook extra approval stappen op het aanvragen van een Azure AD rol te zetten. Dit geldt trouwens ook Active Directory omgevingen, niet alleen voor Azure Active Directory, probleer zo veel mogelijk het principe van least privilege te hanteren en als het budget het toestaat een privileged identity management oplossing zoals bijvoorbeeld CyberArk te implementeren.
https://docs.microsoft.co...-management/pim-configure
Zorg ook voor een goed en doordacht geautomatiseerd identity proces, dat willen zeggen dat Security groepen automatisch worden gevult.
En voor het aanmaken van user accounts zou dat automatisch moeten gaan via een provisoning proces eventueel ondersteunt door software. In de markt zijn daar meerdere oplossing voor zoals bijvoorbeeld UMRA en bijvoorbeeld Identity IQ van Sailpoint. De goedkeuring van de aanvragen die gedaan te worden door een autorisatie management afdeling die de business en compliance regels goed in gaten houdt en ervoor zorgt als een waakhond dat mensen geen toegang toe krijgen waar ze geen toegang toe mogen krijgen uit hun functie.
Client Authentidcatie:
2. Zorg dat iedereen met twee factor authenticeert, met een Authenticator app of met een FIDO2 key met fingerprint. Daarnaast is het in Windows Hello aan te raden om een extra biometrische check te vereisen als de gebruikte hardware dat ondersteunt. De voorkeur geniet om rechtstreeks tegen Azure AD te authenticeren (want dat is mogelijk), en ADFS oplossingen uit te faseren
Daarnaast is het ook raadzaam om zo min mogelijk mensen domain of enterprise admin te maken, en de juiste rechten toe te kennen via groepen die door middel van delegatie de juiste permissies hebben. Ditzelfde geldt voor rollen als Global Admin in Azure tenants. Ook een rol Azure AD Beheerder en Exchange Admin, soms liggen die groepen/rollen bij een en dezelfde persoon, dat is niet erg, maar zorg dat die rollen via een PIM oplossing (bijvoorbeeld Azure Privliged Identity Management) aangevraagd kunnen worden, en dat je instelt dat dit soort maar voor maximaal 2 uur toegekend kunnen zijn
Ook kan Defender for Identity erg waardevol, zijn.
3.Client Management
Zorg dat je een goede client management oplossing hebt waarmee je snel patches en updates kan deployen. Het is ook wel aan te raden om een goede patch management proces in te richten waar ook nagedacht is over emergency patches, zeker bij wat grotere organisaties is dat van belang.
Ik zou ook adviseren om je beheerders te voorzien van extra hardened machines, Microsoft heeft daar de Microsoft Privileged Access Workstation (PAW voor). Dit zorgt ervoor dat je beheerders die de meeste privileges hebben wat extra hardening (securitymaatregelen op het werkstation), omdat de beheerders met veel "high privileged rollen" tegenwoordig best een risico kunnen zijn. Threat Actors (aanvallers) proberen daar ook naar te zoeken bij een aanval. Daarnaast is het raadzaam om de Domain Admin en Enterprise admin accounts niet te gebruiken en te beschouwen als noodaccounts, waar de wachtwoorden van in een kluis liggen, waar alleen toegang tot verkregen kan worden bij een calamiteit.
4.Logging
Zorg dat je een goed security incident proces hebt en zoveel mogelijk logging in een systeem verzamelt waar je het slimme queries of machine learning Azure modellen kunt analyseren. Voorbeelde daarvan zijn Splunk. Ik ben zelf erg gecharmeerd van Azure Sentinel i.s.m Azure Security Center. De voordelen van Azure Sentinel is dat het kan verbinden dmv connectoren met allerlei verschillende systemen en meeten de juiste logging ophaalt (denk aan Azure AD, Microsoft 365 Defender, Azure subscriptie logging, en allerlei andere diensten). Mocht je servers in je datacenter hebben draaien dan kun je de log analytics agent op die omgevingen te intsalleren om zo een completer beeld te krijgen. Daarnaast heeft Microsoft een uniforme query/machine learning taal ontwikkelt, gemaand Kusto Language Query, waar je zelf veel custom dingen kan aanmaken die je wil monitoren. het kan een leercurve zijn, maar KCL queries zijn enorm krachtig of binnen Azure Sentinel allerlei threats te vinden en analytics rules te maken. Mijn advies is om security analisten to laten focussen op threat hunting en zo veel mogelijk gebruik van te maken. KCL queries die er al zijn van Microsoft te gebruiken en daarnaast indien gewenst eigen zaken te monitoren aan de hand van het Cloud Security Beleid. Veelal dient een Information Security Officer met enige cloud kennis daarbij aangehaakt te zijn, om goede kaders en richtlijnen neer te zetten voor een Cloud Security Beleid. Voor de security analisten en security engineers zijn daar verschillende certificering trajecten vanuit Microsoft die ik zeker aanraad om te volgen. Als het is alleen maar om een bepaalde basiskennis op te doen. Hetzelfde zou ik willen aanraden voor de security analisten, dat iedere Security analist die wat met Azure Security doet minimaal de SC-200 heeft gedaan (Microsoft Security Operations Analyst certificering) en M365 of Azure fundamentels als basis. Voor Azure Security Engineer kan het ook waardevol zijn om de AZ-500 (Azure Security Engineer) en voor security engineer die meer bezig zijn met M365 de MS-500. Dat geeft een goede basiskennis om goed aan de slag te kunnen met de Microsoft Cloud Security Stack.
Het verschil tussen security engineer is dat een security engineer zich bezighoudt met de verder ontwikkeling van Azure Sentinel en Security Center en eventueel de M365 security diensten zoals Defender, Cloud App Security. Eigenlijk dus het cloud SIEM platform beheert.
Een security analist is echt op zoek naar risico's en threats binnen de cloud diensten die gebruikt worden. De Azure en M365 fundamentls raad ik omdat een security analist en security engineer meestal veel in aanraking komt Azure en M365 diensten waarin een bepaalde basiskennis daarin heel waardevol kan zijn.
Dan nog een voordeel van Azure Sentinel, er worden op basis van de threats die Microsoft ziet, steeds nieuwe dingen toegevoegd, ook vindt je op de Azure Sentinel github enorm voorbeelden met allerlei KCL "queries", om allerlei diensten te monitoren op gebied van security.
5.Enpoint Security
Voor Endpoint Security zou ik sowieso de microsoft security baselines willen adviseren om te deployen, via Intune(cloud) of Group Policy(on-prem). Daarnaast ben ik erg gecharrnmeerd van Defender for Endpoint, en ook daar zie je de kracht van schaalgrootte terug, omdat Microsoft analyseert de dingen die ze zien op endpoint eerst in je eigen tenant met allerlei slimme Advanced Threat Protection, zoals behaviour monitoring. Daarnaast kun je zelf ook IOC's (Indicators of Compromise) toevoegen, dus hashes van malware bestanden of iets dergelijke.
Daarnaast heeft Microsoft al best een lijst opgebouewd in de security graph die voor iedere tenant gebruikt wordt van applicaties die niet wenselijk zijn op een corporate endpoint (denk aan Bittorrent clients en dergelijke). De backend van Defender for Endpoint is redelijk simpel, je hebt een stuk of 10 features die je aan kan zetten, ik ga ze niet in dit artikel niet allemaal af, omdat je ze heel goed hier kan terugvinden, en dit is natuurlijk constant in onwikkeling:
https://docs.microsoft.co...tures?view=o365-worldwide
Conditional Access
Conditional Access is de basis van een veilige cloud omgeving, en daarmee kun je het ook enorm complex maken.
Zelf ben best gecharmeerd om naar persona's te kijken en op basis daarvan je Conditional Access te ontwerpen.
Daarnaast heeft Claus Jespersen, Principal Security Consultant bij Microsoft daar een enorm goed document over gepubliceerd. Zie dat document als basis inrichting van conditional access, daarnaast kun je natuurlijk op basis van je eigen requirements extra persona's toevoegen.
https://www.linkedin.com/...-6798870787546779648-huo4
Identity"
1.Zo min mogelijk admins met hoge privilige rollen (bijvoorbeeld Global Admin of Security Admin), Global Admin sowieso beperken tot noodaccounts an de rest allemaal toekennen via Azure Privliged Identiy Management. Het voordeel daarvan is dat een admin rol maar voor een x aantal uur toegekend en daarna niet meer actief is. En daarnaast kun je ook extra approval stappen op het aanvragen van een Azure AD rol te zetten. Dit geldt trouwens ook Active Directory omgevingen, niet alleen voor Azure Active Directory, probleer zo veel mogelijk het principe van least privilege te hanteren en als het budget het toestaat een privileged identity management oplossing zoals bijvoorbeeld CyberArk te implementeren.
https://docs.microsoft.co...-management/pim-configure
Zorg ook voor een goed en doordacht geautomatiseerd identity proces, dat willen zeggen dat Security groepen automatisch worden gevult.
En voor het aanmaken van user accounts zou dat automatisch moeten gaan via een provisoning proces eventueel ondersteunt door software. In de markt zijn daar meerdere oplossing voor zoals bijvoorbeeld UMRA en bijvoorbeeld Identity IQ van Sailpoint. De goedkeuring van de aanvragen die gedaan te worden door een autorisatie management afdeling die de business en compliance regels goed in gaten houdt en ervoor zorgt als een waakhond dat mensen geen toegang toe krijgen waar ze geen toegang toe mogen krijgen uit hun functie.
Client Authentidcatie:
2. Zorg dat iedereen met twee factor authenticeert, met een Authenticator app of met een FIDO2 key met fingerprint. Daarnaast is het in Windows Hello aan te raden om een extra biometrische check te vereisen als de gebruikte hardware dat ondersteunt. De voorkeur geniet om rechtstreeks tegen Azure AD te authenticeren (want dat is mogelijk), en ADFS oplossingen uit te faseren
Daarnaast is het ook raadzaam om zo min mogelijk mensen domain of enterprise admin te maken, en de juiste rechten toe te kennen via groepen die door middel van delegatie de juiste permissies hebben. Ditzelfde geldt voor rollen als Global Admin in Azure tenants. Ook een rol Azure AD Beheerder en Exchange Admin, soms liggen die groepen/rollen bij een en dezelfde persoon, dat is niet erg, maar zorg dat die rollen via een PIM oplossing (bijvoorbeeld Azure Privliged Identity Management) aangevraagd kunnen worden, en dat je instelt dat dit soort maar voor maximaal 2 uur toegekend kunnen zijn
Ook kan Defender for Identity erg waardevol, zijn.
3.Client Management
Zorg dat je een goede client management oplossing hebt waarmee je snel patches en updates kan deployen. Het is ook wel aan te raden om een goede patch management proces in te richten waar ook nagedacht is over emergency patches, zeker bij wat grotere organisaties is dat van belang.
Ik zou ook adviseren om je beheerders te voorzien van extra hardened machines, Microsoft heeft daar de Microsoft Privileged Access Workstation (PAW voor). Dit zorgt ervoor dat je beheerders die de meeste privileges hebben wat extra hardening (securitymaatregelen op het werkstation), omdat de beheerders met veel "high privileged rollen" tegenwoordig best een risico kunnen zijn. Threat Actors (aanvallers) proberen daar ook naar te zoeken bij een aanval. Daarnaast is het raadzaam om de Domain Admin en Enterprise admin accounts niet te gebruiken en te beschouwen als noodaccounts, waar de wachtwoorden van in een kluis liggen, waar alleen toegang tot verkregen kan worden bij een calamiteit.
4.Logging
Zorg dat je een goed security incident proces hebt en zoveel mogelijk logging in een systeem verzamelt waar je het slimme queries of machine learning Azure modellen kunt analyseren. Voorbeelde daarvan zijn Splunk. Ik ben zelf erg gecharmeerd van Azure Sentinel i.s.m Azure Security Center. De voordelen van Azure Sentinel is dat het kan verbinden dmv connectoren met allerlei verschillende systemen en meeten de juiste logging ophaalt (denk aan Azure AD, Microsoft 365 Defender, Azure subscriptie logging, en allerlei andere diensten). Mocht je servers in je datacenter hebben draaien dan kun je de log analytics agent op die omgevingen te intsalleren om zo een completer beeld te krijgen. Daarnaast heeft Microsoft een uniforme query/machine learning taal ontwikkelt, gemaand Kusto Language Query, waar je zelf veel custom dingen kan aanmaken die je wil monitoren. het kan een leercurve zijn, maar KCL queries zijn enorm krachtig of binnen Azure Sentinel allerlei threats te vinden en analytics rules te maken. Mijn advies is om security analisten to laten focussen op threat hunting en zo veel mogelijk gebruik van te maken. KCL queries die er al zijn van Microsoft te gebruiken en daarnaast indien gewenst eigen zaken te monitoren aan de hand van het Cloud Security Beleid. Veelal dient een Information Security Officer met enige cloud kennis daarbij aangehaakt te zijn, om goede kaders en richtlijnen neer te zetten voor een Cloud Security Beleid. Voor de security analisten en security engineers zijn daar verschillende certificering trajecten vanuit Microsoft die ik zeker aanraad om te volgen. Als het is alleen maar om een bepaalde basiskennis op te doen. Hetzelfde zou ik willen aanraden voor de security analisten, dat iedere Security analist die wat met Azure Security doet minimaal de SC-200 heeft gedaan (Microsoft Security Operations Analyst certificering) en M365 of Azure fundamentels als basis. Voor Azure Security Engineer kan het ook waardevol zijn om de AZ-500 (Azure Security Engineer) en voor security engineer die meer bezig zijn met M365 de MS-500. Dat geeft een goede basiskennis om goed aan de slag te kunnen met de Microsoft Cloud Security Stack.
Het verschil tussen security engineer is dat een security engineer zich bezighoudt met de verder ontwikkeling van Azure Sentinel en Security Center en eventueel de M365 security diensten zoals Defender, Cloud App Security. Eigenlijk dus het cloud SIEM platform beheert.
Een security analist is echt op zoek naar risico's en threats binnen de cloud diensten die gebruikt worden. De Azure en M365 fundamentls raad ik omdat een security analist en security engineer meestal veel in aanraking komt Azure en M365 diensten waarin een bepaalde basiskennis daarin heel waardevol kan zijn.
Dan nog een voordeel van Azure Sentinel, er worden op basis van de threats die Microsoft ziet, steeds nieuwe dingen toegevoegd, ook vindt je op de Azure Sentinel github enorm voorbeelden met allerlei KCL "queries", om allerlei diensten te monitoren op gebied van security.
5.Enpoint Security
Voor Endpoint Security zou ik sowieso de microsoft security baselines willen adviseren om te deployen, via Intune(cloud) of Group Policy(on-prem). Daarnaast ben ik erg gecharrnmeerd van Defender for Endpoint, en ook daar zie je de kracht van schaalgrootte terug, omdat Microsoft analyseert de dingen die ze zien op endpoint eerst in je eigen tenant met allerlei slimme Advanced Threat Protection, zoals behaviour monitoring. Daarnaast kun je zelf ook IOC's (Indicators of Compromise) toevoegen, dus hashes van malware bestanden of iets dergelijke.
Daarnaast heeft Microsoft al best een lijst opgebouewd in de security graph die voor iedere tenant gebruikt wordt van applicaties die niet wenselijk zijn op een corporate endpoint (denk aan Bittorrent clients en dergelijke). De backend van Defender for Endpoint is redelijk simpel, je hebt een stuk of 10 features die je aan kan zetten, ik ga ze niet in dit artikel niet allemaal af, omdat je ze heel goed hier kan terugvinden, en dit is natuurlijk constant in onwikkeling:
https://docs.microsoft.co...tures?view=o365-worldwide