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
Reacties
Ik zal dit stukje proza eens laten lezen door m'n moeder. Kan je lachen...
Leuk om eens wat anders te lezen op een blog hier!
Het is een behoorlijk breed onderwerp en verandert sneller dan dat je bij kan houden. Heb je ook voorbeelden uit de praktijk van wat er mogelijk is tegengehouden? Wat een leverancier voorstelt en wat de theorie is, is nog niet altijd de praktijk.
Probeer maar eens een bestaande complexe enterprise AD omgeving met een sync/federation naar Azure AD veiliger te krijgen, zonder dat de gehele IT/business vast loopt.
Het is een behoorlijk breed onderwerp en verandert sneller dan dat je bij kan houden. Heb je ook voorbeelden uit de praktijk van wat er mogelijk is tegengehouden? Wat een leverancier voorstelt en wat de theorie is, is nog niet altijd de praktijk.
Probeer maar eens een bestaande complexe enterprise AD omgeving met een sync/federation naar Azure AD veiliger te krijgen, zonder dat de gehele IT/business vast loopt.
Allereerst leuk artikel, top dat je de diverse onderwerpen inhoudelijk hebt beschreven. klasse!
Ik zit al 25 jr in het vak en heb alle transities van "hoi we willen internet en inbellen met een modem/isdn" Tot hoogste regionen van fortinet / checkpoint security meegemaakt en alles wat er tussen zit.
Het onderwerp over je beheerders zou ik graag wat willen nuanceren, waarom? Een beheerder vertrouw je, Als een beginnende beheerder te weinig kennis heeft leidt je die op, leg je zaken uit en leer je dingen. Iemand digitaal afknijpen voor 2 uurtjes kan diegene in die 2 uur net zoveel stuk maken als dat hij elke dag toegang heeft tot het systeem.
In mijn begin jaren was ik ook van de policies, afbakenen, eilandjes creëren, "ik kan meer als jij" taktiek,.... en als je ouder en langer in het vak zit leer je dat het beter is om goede beheerders om je heen te verzamelen en kennis te delen zodat iedereen slimmer wordt en minder eilandjes zijn. waarom?
T werkt sneller, taken kan je immers verdelen, kennis nivo is hoger bij je beheerders dus bij uitdagingen kan je deze samen aanvliegen en je beheerders blijven bij je bedrijf werken omdat ze gemotiveerd zijn en verantwoordelijkheden kunnen dragen. En technisch je beheerders met de vingers tussen de bankschroef zetten is het domste wat je kan doen binnen een IT organisatie die het bedrijfsproces ondersteund. (Er vanuit gaande dat de rollen helder zijn binnen je organisatie, dus een SQL beheerder is een database man en geen systeembeheerder. (kennis).
Dus top dat je de tools hebt, maar mensen op training sturen, verantwoording en inzicht geven waar ze op moeten letten en deze verantwoording ook laten dragen brengt je verder dan alles maar dicht metselen.

Ik zit al 25 jr in het vak en heb alle transities van "hoi we willen internet en inbellen met een modem/isdn" Tot hoogste regionen van fortinet / checkpoint security meegemaakt en alles wat er tussen zit.
Het onderwerp over je beheerders zou ik graag wat willen nuanceren, waarom? Een beheerder vertrouw je, Als een beginnende beheerder te weinig kennis heeft leidt je die op, leg je zaken uit en leer je dingen. Iemand digitaal afknijpen voor 2 uurtjes kan diegene in die 2 uur net zoveel stuk maken als dat hij elke dag toegang heeft tot het systeem.
In mijn begin jaren was ik ook van de policies, afbakenen, eilandjes creëren, "ik kan meer als jij" taktiek,.... en als je ouder en langer in het vak zit leer je dat het beter is om goede beheerders om je heen te verzamelen en kennis te delen zodat iedereen slimmer wordt en minder eilandjes zijn. waarom?
T werkt sneller, taken kan je immers verdelen, kennis nivo is hoger bij je beheerders dus bij uitdagingen kan je deze samen aanvliegen en je beheerders blijven bij je bedrijf werken omdat ze gemotiveerd zijn en verantwoordelijkheden kunnen dragen. En technisch je beheerders met de vingers tussen de bankschroef zetten is het domste wat je kan doen binnen een IT organisatie die het bedrijfsproces ondersteund. (Er vanuit gaande dat de rollen helder zijn binnen je organisatie, dus een SQL beheerder is een database man en geen systeembeheerder. (kennis).
Dus top dat je de tools hebt, maar mensen op training sturen, verantwoording en inzicht geven waar ze op moeten letten en deze verantwoording ook laten dragen brengt je verder dan alles maar dicht metselen.
Je begrijpt mogelijk het risico van wat jij beschrijft en zijn aangedragen oplossing niet.itlee schreef op woensdag 28 juli 2021 @ 11:34:
In mijn begin jaren was ik ook van de policies, afbakenen, eilandjes creëren, "ik kan meer als jij" taktiek,.... en als je ouder en langer in het vak zit leer je dat het beter is om goede beheerders om je heen te verzamelen en kennis te delen zodat iedereen slimmer wordt en minder eilandjes zijn. waarom?
T werkt sneller, taken kan je immers verdelen, kennis nivo is hoger bij je beheerders dus bij uitdagingen kan je deze samen aanvliegen en je beheerders blijven bij je bedrijf werken omdat ze gemotiveerd zijn en verantwoordelijkheden kunnen dragen. En technisch je beheerders met de vingers tussen de bankschroef zetten is het domste wat je kan doen binnen een IT organisatie die het bedrijfsproces ondersteund. (Er vanuit gaande dat de rollen helder zijn binnen je organisatie, dus een SQL beheerder is een database man en geen systeembeheerder. (kennis).
Het gaat er niet om om eilandjes te maken, het gaat erom geen accounts te hebben die 100% van de tijd overal maar rechten hebben. Als jij kennis hebt van SQL en iets moet doen op de sql server, dan geeft de privilege access management oplossing jou een account voor een aantal uur op het moment dat je dat nodig hebt. Na die tijd wordt het ingetrokken.
Jij hebt dus op elk moment de mogelijkheid om ook maar wat te doen wat je wilt. Er worden geen eilandjes gemaakt. We gaan ook niet zeggen "ik mag meer dan jij". Er wordt geen kennisdelen blokkade neergelegd. Er wordt alleen voor gezorgd dat jou account niet continue de masterkey heeft om overal alles te kunnen doen.
Waarom niet?
Omdat als een hacker binnenkomt en hij jou identiteit steelt, hij in jou geval overal altijd bij kan. In het geval van de blog kan die dat niet. Jou account is namelijk alleen maar normale gebruiker. Als jij iets moet doen, krijg jij een tijdelijk ander account met de rechten die je op dat moment nodig hebt voor een bepaald systeem en daarna wordt dat account destroyed. Die hacker kan dus wel jou identiteit stelen van dat moment, maar daar heeft hij maar kort wat aan of hij moet het gaan aanvragen, maar dan gaat het systeem, wat deze accounts uitdeelt, piepen.
@itlee
En elke chauffeur op de baan is overtuigd dat ze zelf nooit een ongeval zullen veroorzaken.
Als iemand die nog geen 25 jaar in het vak zit maar ondertussen wel zijn strepen heeft verdiend, ben ik net een grote voorstander van MFA, PIM en PAM. Ik heb bijna dagelijks global admin access nodig binnen Azure AD, maar heb niet het gevoel dat die technologieën een rem zijn. Cybersecurity aanvallen worden steeds complexer en veel gerichter omdat er grof geld mee te verdienen valt. Je hebt er als IT'er alle baat bij om die attack vector zo klein mogelijk te maken en dat begint bij de accounts met de meeste rechten.
En elke chauffeur op de baan is overtuigd dat ze zelf nooit een ongeval zullen veroorzaken.
Als iemand die nog geen 25 jaar in het vak zit maar ondertussen wel zijn strepen heeft verdiend, ben ik net een grote voorstander van MFA, PIM en PAM. Ik heb bijna dagelijks global admin access nodig binnen Azure AD, maar heb niet het gevoel dat die technologieën een rem zijn. Cybersecurity aanvallen worden steeds complexer en veel gerichter omdat er grof geld mee te verdienen valt. Je hebt er als IT'er alle baat bij om die attack vector zo klein mogelijk te maken en dat begint bij de accounts met de meeste rechten.
Mooi stukje, dank!
Ik ben bij ons (MSP) bezig om de security naar een hoger plan te tillen, dit is nuttige info waar ik zelf ook al mee bezig was.
Ik ben bij ons (MSP) bezig om de security naar een hoger plan te tillen, dit is nuttige info waar ik zelf ook al mee bezig was.
Interessante post!
@itlee
Ik moet SunnyNL en iStealYourGun gelijk geven. Goede account beveiliging hoeft niet te betekenen dat je bepaalde taken gaat afschermen. Ik zou zelfs zeggen: in tegendeel. Je kan eigenlijk net meer rechten geven aan mensen dan wat ze vandaag hebben wanneer er simpelweg een verantwoording moet komen wanneer ze op een bepaald moment bepaalde toegang wensen te hebben.
Wij zijn ondertussen zo ver dat onze customer support toegang kan krijgen tot de systemen van klanten afhankelijk van het ticket waaraan zij werken. Staan zij toegewezen aan een ticket voor klant X dan krijgen zij toegang tot de systemen van klant X voor zolang zij toegewezen staan en het ticket niet is afgesloten.
Ik heb de afgelopen jaren implementaties meegemaakt van zowel PIM als PAM en je merkt telkens tegenkanting van gebruikers. Niet onverwacht want verandering stoot altijd op verzet. Maar ondanks dat het mij ook treft in mijn dageijks werk ben ik wel voorstander. Zeker als je ziet hoe eenvoudig aanvallers soms in je netwerk kunnen komen en als ze er eenmaal zijn, hoe snel ze daarna schade kunnen aanrichten.
Ik moet SunnyNL en iStealYourGun gelijk geven. Goede account beveiliging hoeft niet te betekenen dat je bepaalde taken gaat afschermen. Ik zou zelfs zeggen: in tegendeel. Je kan eigenlijk net meer rechten geven aan mensen dan wat ze vandaag hebben wanneer er simpelweg een verantwoording moet komen wanneer ze op een bepaald moment bepaalde toegang wensen te hebben.
Wij zijn ondertussen zo ver dat onze customer support toegang kan krijgen tot de systemen van klanten afhankelijk van het ticket waaraan zij werken. Staan zij toegewezen aan een ticket voor klant X dan krijgen zij toegang tot de systemen van klant X voor zolang zij toegewezen staan en het ticket niet is afgesloten.
Ik heb de afgelopen jaren implementaties meegemaakt van zowel PIM als PAM en je merkt telkens tegenkanting van gebruikers. Niet onverwacht want verandering stoot altijd op verzet. Maar ondanks dat het mij ook treft in mijn dageijks werk ben ik wel voorstander. Zeker als je ziet hoe eenvoudig aanvallers soms in je netwerk kunnen komen en als ze er eenmaal zijn, hoe snel ze daarna schade kunnen aanrichten.
Maar... dan heb je toch gewoon een account met alle rechten? Je moet alleen even op een knop drukken om ergens bij te kunnen, maar die knop kán je indrukken dus heb je eigenlijk al alle rechten. Dan veranderd het niet zo gek veel.SunnieNL schreef op woensdag 28 juli 2021 @ 15:46:
[...]
Als jij kennis hebt van SQL en iets moet doen op de sql server, dan geeft de privilege access management oplossing jou een account voor een aantal uur op het moment dat je dat nodig hebt. Na die tijd wordt het ingetrokken.
Jij hebt dus op elk moment de mogelijkheid om ook maar wat te doen wat je wilt. [...]
Disclaimer: ik ben geen beheerder, dus ik heb geen flauw idee hoe dit in de praktijk afspeelt. Vind het daarom wel een interessante discussie. (Ik zit in de software-hoek.)
Hangt er vanaf welke rollen er aan toegekend zijn en welke rollen je kan aanvragen, als je het goed doet, probeer je altijd het principe least privilege te hanteren. Dus welke rechten heb je minimaal nodig om je werk te kunnen doen en meer nietxFeverr schreef op dinsdag 3 augustus 2021 @ 09:59:
[...]
Maar... dan heb je toch gewoon een account met alle rechten? Je moet alleen even op een knop drukken om ergens bij te kunnen, maar die knop kán je indrukken dus heb je eigenlijk al alle rechten. Dan veranderd het niet zo gek veel.
Disclaimer: ik ben geen beheerder, dus ik heb geen flauw idee hoe dit in de praktijk afspeelt. Vind het daarom wel een interessante discussie. (Ik zit in de software-hoek.)
[Reactie gewijzigd op dinsdag 3 augustus 2021 10:38]
Reageren is niet meer mogelijk