ISO - Domain users wel of geen local admin rechten geven?

[k4sual]

Ik en mijn collega-systeembeheerders worstelen momenteel met het volgende.

Vanuit onze ISO certificering heeft ons management er een aantal maanden geleden voor gekozen om alle local admin rechten op de Windows PC's te ontnemen van onze domain users. Dit heeft nu als gevolg dat bij iedere update of installatie van wat voor vorm dan ook, de user wordt gevraagd om domain admin credentials in te voeren. Nu worden veel van de applicaties die wij gebruiken helemaal 'kapot' geupdate, en je voelt hem al aankomen met 50 werknemers; je moet dagelijks bij meerdere users langslopen of remote een PC overnemen om de credentials in te voeren. Veel van deze applicaties kunnen wij ook helaas niet gecentraliseerd patchen. Kleine moeite, maar erg praktisch is het simpelweg niet, voor ons niet maar ook niet voor onze eindgebruikers. Nu moet je natuurlijk altijd een afweging maken tussen gebruiksgemak en beveiliging, maar ik ben toch benieuwd hoe jullie hier als 'ervaringsdeskundigen' tegenaan kijken.

- Stel dat wij er nu voor kiezen om onze eindgebruikers toch weer local admin rechten te geven op hun PC's, wat zijn hier dan de nadelen/risico's van? En is er een manier waarop wij users toch de rechten kunnen geven en de risico's tot een minimum kunnen beperken?

- Ik kan mij haast niet voorstellen dat andere grote(re) bedrijven ook op deze manier te werken gaan. Iemand voorbeelden van hoe dit bij andere bedrijven eraan toegaat? Of andere systeembeheerders die met dit dilemma te maken hebben gehad?

Voor jullie beeldvorming, we werken op een on-premise Windows Server omgeving met Windows 10/11 computers die verbonden zijn met het domein.

Alle tips en tricks zijn van harte welkom, ben benieuwd.

[DDX]

Proberen toch zaken te automatiseren.
Scripting om te updaten/tooling zoals bijvoorbeeld intune/chocolatey.

Ook omdat je dan zeker weet dat updates ook echt gedaan worden, als je dat bij gebruikers neerlegt kiezen ze vaak voor optie doe later maar.

En voor ISO kan je altijd een procedure schrijven dat je vanuit directie uitzonderingen maakt voor bepaalde mensen/functiegroepen.
Al is het maar om jezelf wel local admin rechten te geven ?
Maar bij ons krijgen developers ook local admin rechten, omdat het anders onwerkbaar is kwa IIS instellingen zaken bijvoorbeeld.
Hierover krijgen ze dan wel een mail met info wat wel en niet de bedoeling hiervan is. (en dat bij misbruik deze rechten ingetrokken worden)

[ Voor 10% gewijzigd door DDX op 07-04-2022 15:45 ]

[The Lord]

k4sual schreef op donderdag 7 april 2022 @ 15:21:
Ik en mijn collega-systeembeheerders worstelen momenteel met het volgende.

Vanuit onze ISO certificering heeft ons management er een aantal maanden geleden voor gekozen om alle local admin rechten op de Windows PC's te ontnemen van onze domain users. Dit heeft nu als gevolg dat bij iedere update of installatie van wat voor vorm dan ook, de user wordt gevraagd om domain admin credentials in te voeren. Nu worden veel van de applicaties die wij gebruiken helemaal 'kapot' geupdate, en je voelt hem al aankomen met 50 werknemers; je moet dagelijks bij meerdere users langslopen of remote een PC overnemen om de credentials in te voeren. Veel van deze applicaties kunnen wij ook helaas niet gecentraliseerd patchen. Kleine moeite, maar erg praktisch is het simpelweg niet, voor ons niet maar ook niet voor onze eindgebruikers. Nu moet je natuurlijk altijd een afweging maken tussen gebruiksgemak en beveiliging, maar ik ben toch benieuwd hoe jullie hier als 'ervaringsdeskundigen' tegenaan kijken.

- Stel dat wij er nu voor kiezen om onze eindgebruikers toch weer local admin rechten te geven op hun PC's, wat zijn hier dan de nadelen/risico's van? En is er een manier waarop wij users toch de rechten kunnen geven en de risico's tot een minimum kunnen beperken?

worst case risico: bij een *ware besmetting, disgruntled employee, etc. volledig verlies van alles. Afhankelijk of er aanvullende maatregelen zijn genomen om het risico te mitigeren.

- Ik kan mij haast niet voorstellen dat andere grote(re) bedrijven ook op deze manier te werken gaan. Iemand voorbeelden van hoe dit bij andere bedrijven eraan toegaat? Of andere systeembeheerders die met dit dilemma te maken hebben gehad?

Er zijn ook 'managed one-time-elevated-privlige' oplossingen. Of er wordt heel kritisch naar de software en benodigd patch-management gekeken. De verschillende mogelijkheden afzetten in TCO geeft een goed beeld van wat het betekent.

[nst6ldr]

Waarom je geen local admin rechten wil geven is een inkoppertje: als local admin heb je controle over het systeem, en kan je dus lokale maatregelen uitzetten (zoals virusscanners). Ook maak je het makkelijk om bijvoorbeeld wachtwoorden van andere mensen die van jouw computer gebruik maken te stelen, aangezien je kan installeren wat je wilt.

Grotere bedrijven doen dit met behulp van deployment tools als bijvoorbeeld SCCM. Er word een service account gemaakt met local admin rechten, en de SCCM agent draait onder die user context. Via SCCM rol je een package uit -> de agent op de client pikt dat op en installeert het.

[Zethiel]

Veel van deze applicaties kunnen wij ook helaas niet gecentraliseerd patchen.

Waarom niet? Nu je 50 collega's hebt is het handmatig doen nog een kleine moeite (hoe klein deze moeite is vraag ik me af), wat nu als het bedrijf ineens hard gaat groeien? Ik zou deployment tools gaan onderzoeken voor je omgeving, zoals de hierboven genoemde SCCM bijvoorbeeld, daarmee is het bijhouden van applicaties een nog veel kleinere moeite als je eenmaal alles hebt ingericht.

Voor user rechten wil je uitgaan van Principle of least privilege (Polp), alleen de rechten die gebruikers nodig hebben om hun werkzaamheden uit te kunnen voeren (https://www.cyberark.com/what-is/least-privilege/)

[sh4d0wman]

Hier nog nuttige tips van MS: https://docs.microsoft.co...ege-administrative-models

Monitor in ieder geval een Service account en let op dat het niet gebruikt kan worden om remote op andere machines aan te melden. Veel ellende komt van lateral movement met een gecompromiteerd account

Vergeet ook niet eens kritisch je active directory te bekijken als je toch met ISO bezig bent.
Enkele quick wins, veel voorkomende misconfigurations die misbruikt worden: YouTube: Hacking Common AD Misconfigurations

[Deveon]

Veel van deze applicaties kunnen wij ook helaas niet gecentraliseerd patchen.

Zoek eens naar "patchmypc", zij bieden de meeste applicaties aan als standaard packages en updates. Afhankelijk van de omgeving is het even zoeken hoe je het beste kan distribueren. Wij doen het via SCCM, maar kan ook prima via WSUS of met hun eigen tooling.

Voor de specialistische gebruikers bieden wij aparte beheer accounts die alleen op hun eigen device beheer rechten hebben. De configuratie hiervan gaat allemaal via GPP.

[ Voor 19% gewijzigd door Deveon op 07-04-2022 15:57 ]

[Deveon]

Zethiel schreef op donderdag 7 april 2022 @ 15:45:
[...]
zoals de hierboven genoemde SCCM bijvoorbeeld

SCCM voor 50 werkplekken? Dat is de inrichting echt niet waard en LCM van applicaties is enorm omslachtig, als je zulk budget hebt is de cloud variant van Endpoint Manager veel interessanter (bekend als Intune).

[Hogarts]

Noem eens wat van die applicaties dan?

Want praktisch gezien ken ik tegenwoordig toch weinig (behalve custom / maatwerk apps) apps die nog local admin nodig hebben.

Juist vanuit de grote bedrijven wordt er al decennia geschreeuwd dat local admin apps niet gewenst zijn en de meeste serieuzere apps die houden zich daaraan.
En bij de kleinere apps is het gewoon goed kijken.
- Sommige bied de leverancier een andere variant aan die geen local admin vereist
- Sommige zijn makkelijk te scripten dan script je die.
- Sommige hebben concurrenten die het wel behoorlijk aanbieden en dan mieter je de huidige variant eruit.
- Sommige zijn gewoon inherent ongewenst, die mieter je er per definitie uit.
- Sommige zijn niet zo update-gevoelig en die kan je bijv bundelen door gewoon 1x per 2 maanden een update-ronde uit te voeren en dan doe je gewoon een paar apps per pc.

Uitspraken als "je moet dagelijks bij meerdere users langslopen of remote een PC overnemen om de credentials in te voeren." vragen er gewoon om om het eens een maand te klokken en dan naar directie te stappen met de mededeling : Ik zit xx uur per maand mijn tijd te verdoen, hoeveel geld is er beschikbaar om dit omlaag te krijgen.

Let er trouwens wel op dat er nog een gigantisch verschil zitten tussen local admin credentials en Domain admin credentials (die jullie nu blijkbaar invoeren)...
Ik ken bijv een situatie die vanuit aantal werkplekken niet efficiënt via software viel te updaten (en er was veel maatwerk software) alleen daar kreeg gewoon de telefoniste het local admin wachtwoord (inclusief verantwoordelijkheid etc) zodat zij het bij iedereen kon copy-pasten, het was bij lange na nog niet ideaal, maar wel tig keer goedkoper als dat de beheerder zich hiermee bezig ging houden.
Waardoor beheerder allerlei tijd vrijkreeg en een half jaar later werden de local admin wachtwoorden per dag gereset waardoor als de telefoniste het zou vrijgeven dan was het maar 1 dag geldig.

Simpelweg het 1e wat je moet doen is tijd vrijmaken om over een oplossing na te kunnen denken, anders blijf je in een eeuwige cirkel draaien, dat je geen tijd hebt om iets goeds te gaan implementeren omdat je bezig bent met werk wat je niet moet doen.

[Hubert]

https://batchpatch.com/

[HKLM_]

Zethiel schreef op donderdag 7 april 2022 @ 15:45:
[...]


Waarom niet? Nu je 50 collega's hebt is het handmatig doen nog een kleine moeite (hoe klein deze moeite is vraag ik me af), wat nu als het bedrijf ineens hard gaat groeien? Ik zou deployment tools gaan onderzoeken voor je omgeving, zoals de hierboven genoemde SCCM bijvoorbeeld, daarmee is het bijhouden van applicaties een nog veel kleinere moeite als je eenmaal alles hebt ingericht.

Voor user rechten wil je uitgaan van Principle of least privilege (Polp), alleen de rechten die gebruikers nodig hebben om hun werkzaamheden uit te kunnen voeren (https://www.cyberark.com/what-is/least-privilege/)

Ik zou voor 50 users geen SCCM inrichten maar vol inzetten op Microsoft Endpoint Manager via Intune.
Daar MDM en MAM Configuration en je werkplekbeheerder en patchbeleid heb je op orde

[Zethiel]

Deveon schreef op donderdag 7 april 2022 @ 15:59:
[...]

SCCM voor 50 werkplekken? Dat is de inrichting echt niet waard en LCM van applicaties is enorm omslachtig, als je zulk budget hebt is de cloud variant van Endpoint Manager veel interessanter (bekend als Intune).

Nee klopt inderdaad, dat is iets te veel van het goede, maar er zijn vast alternatieven te vinden voor zijn situatie.

[The Eagle]

Ik gok dat de meeste applicaties die ze draaien dan met admin rechten geinstalleerd zijn door de lokale user.
Long story short: zorgen dat applicaties voortaan onder een non-personal user geinstalleerd worden, en updates uitzetten. Als het draait draait het.

Verder: mijn huidige klant heeft de mogelijkheid voor een user een admin-account aan te vragen. dat wordt dan a<username> en daarmee heb je local admin rights. Kun je het zelf. Maar moet approved worden (door management) met opgaaf van redenen.
Probleem daar leggen waar het hoort heet dat

[HKLM_]

The Eagle schreef op donderdag 7 april 2022 @ 16:36:
Ik gok dat de meeste applicaties die ze draaien dan met admin rechten geinstalleerd zijn door de lokale user.
Long story short: zorgen dat applicaties voortaan onder een non-personal user geinstalleerd worden, en updates uitzetten. Als het draait draait het.

Verder: mijn huidige klant heeft de mogelijkheid voor een user een admin-account aan te vragen. dat wordt dan a<username> en daarmee heb je local admin rights. Kun je het zelf. Maar moet approved worden (door management) met opgaaf van redenen.
Probleem daar leggen waar het hoort heet dat

Adviseer jij nou gewoon om applicaties niet te patchen?

[Deveon]

Hogarts schreef op donderdag 7 april 2022 @ 16:23:
Let er trouwens wel op dat er nog een gigantisch verschil zitten tussen local admin credentials en Domain admin credentials (die jullie nu blijkbaar invoeren)...

Dit inderdaad, op een werkplek inloggen met de domain admin is voor mij direct reden om die rechten in te trekken. Sterker nog, het hoort niet mogelijk te zijn. De werkplek is het riool wat betreft security dankzij mail en internet toegang in handen van een gebruiker en het is een kwestie van tijd totdat die gecomprimeerd wordt.

[Hogarts]

Hubert schreef op donderdag 7 april 2022 @ 16:27:
https://batchpatch.com/

Dit is net als chocolatey en winget en nog tig andere utils hele leuke software.

Alleen het valt of staat met de support die er is op de probleemsoftware.

Als dat niet mainstream is dan helpen al dit soort utilities je weinig.

Dus voordat je begint aan tooltjes etc maak eerst eens een inventarisatie van wat de probleem software is.
In mijn ervaring vervalt dan al bijna gelijk een hele hoop software omdat het gewoon bedrijfsmatig niet nodig is. Het is heel leuk dat een gebruiker het handig vindt, maar als het gewoon 2 uur per maand aan onderhoud kost en de gebruiker slechts een kwartier per maand aan voordeel oplevert dan moet je het er gewoon uitgooien, het kost meer dan dat het opbrengt.

[Deveon]

Zethiel schreef op donderdag 7 april 2022 @ 16:32:
[...]


Nee klopt inderdaad, dat is iets te veel van het goede, maar er zijn vast alternatieven te vinden voor zijn situatie.

Het kan ook via MDT en dat draait in 2-3 uurtjes, maar de support daarop vervalt binnenkort en Intune/Endpoint Manager is dan een véél betere keus om resources in te investeren.

[Hogarts]

HKLM_ schreef op donderdag 7 april 2022 @ 16:37:
[...]
Adviseer jij nou gewoon om applicaties niet te patchen?

Voor een heleboel software is dat wmb een legitieme keuze.

Simpelweg de security patches van die software bekijken en dan beslissen of het nodig is of niet.

Gigantisch veel software wordt geïnstalleerd om 1 ding op te lossen en krijgt daarna 10.000 feature-updates die niet relevant zijn.
Is het een security patch dan doorvoeren.
Maar is het een 0,00001% betere compressie van 7-zip wat is dan de daadwerkelijke relevantie?

[DDX]

Exact is een leuke, maar die wil je niet zomaar updaten op een client want versies van alle clients en server moet gelijk lopen.
Dus pas updaten als het echt moet en dan gewoon even tijd er voor uit trekken.
Draait bij ons ook niet op veel client systemen.
Zou het dat wel doen zou ik voor Exact eerder kijken naar oplossing om het als terminal service remoteapp aan te bieden aan de clients. (of hoe microsoft dat tegenwoordig ook precies noemt)

[Rolfie]

Klinkt als of er niet goed nagedacht is over de aanpassingen.

Maar stap 1 is eigenlijk software development vereenvoudigen en dit goed inrichten.

SCCM kan, maar is best complex.
Alternatief indien mogelijk InTune.

Of een paar goede alternatieven:
PDQ Deploy
Desktop Central

En er zijn natuurlijk nog wel wat mogelijkheden om gebruikers eventueel centraal beheerd 1 dag admin rechten te geven. Natuurlijk wel gescript.

[Hogarts]

Rolfie schreef op donderdag 7 april 2022 @ 16:54:
Klinkt als of er niet goed nagedacht is over de aanpassingen.

Maar stap 1 is eigenlijk software development vereenvoudigen en dit goed inrichten.

SCCM kan, maar is best complex.
Alternatief indien mogelijk InTune.

Of een paar goede alternatieven:
PDQ Deploy
Desktop Central

En er zijn natuurlijk nog wel wat mogelijkheden om gebruikers eventueel centraal beheerd 1 dag admin rechten te geven. Natuurlijk wel gescript.

Klinkt allemaal leuk, maar gaat allemaal enkel op voor standaardsoftware.

Als ik een maatwerkpakketje maak wat zich elke keer anders installeert dan heb je met al deze pakketten elke update weer een scripting uitdaging en is het bij 50 werkplekken wellicht wel goedkoper om gewoon even te klikken dan om 2 uur per update te gaan scripten.

Het hangt allemaal van de software af, en bij de betere software heb je in principe al die extra tools vrijwel niet nodig omdat het ook gewoon via windows zelf kan.
En bij de smerigere software leveren al die tools je meer werk op omdat het scripten langer duurt dan op ok klikken.

Oftewel ga niet meteen met software gooien, maar maak eerst een inventarisatie en overzicht.

[Deveon]

DDX schreef op donderdag 7 april 2022 @ 16:51:
Exact is een leuke, maar die wil je niet zomaar updaten op een client want versies van alle clients en server moet gelijk lopen.
Dus pas updaten als het echt moet en dan gewoon even tijd er voor uit trekken.
Draait bij ons ook niet op veel client systemen.
Zou het dat wel doen zou ik voor Exact eerder kijken naar oplossing om het als terminal service remoteapp aan te bieden aan de clients. (of hoe microsoft dat tegenwoordig ook precies noemt)

Huidige best practice is denk ik als MSIX aanbieden. Soort nieuwe app-v want het is ook zonde om een terminal server omgeving te draaien voor je Exact client.

En dat is dan ook vaak het punt, er zijn 1001 oplossingen en per omgeving zal je de balans moeten zoeken om tot een totaal beeld te komen. Wat werkt voor de ene organisatie kan net door dat ene pakketje waardeloos zijn voor een andere. Daarnaast zijn techneuten vaak geneigd om producten waarmee ze ervaring hebben voor te stellen. Als je de expertise niet intern is win je enorm veel tijd door een externe partij in te schakelen, functioneel de eisen en wensen neerleggen en het inclusief beheer documentatie laten overdragen. Het helpt ook om in ieder geval één van de interne beheerders ook een cursus te laten volgen zodat beter begrip met de externe ontstaat, ze kan wijzen op de nieuwste best practices (vinden ze niet leuk) en daarmee ook expertise kan polsen. Tegenwoordig zie ik steeds meer prutsers ingehuurd worden.

[The Eagle]

HKLM_ schreef op donderdag 7 april 2022 @ 16:37:
[...]


Adviseer jij nou gewoon om applicaties niet te patchen?

Ik zeg updates uitzetten. Op de clients. Da's niet het zelfde als niet patchen of updaten. De vraag is waar en hoe je dat dan wel doet, en waarom.
Altijd up tot date applicatie is niet nodig. Je installeert een applicatie om functie a, b of c te kunnen doen. Dat doet ie. Done. Dan hoeft die applicatie niet dagelijks bij zijn producent te gaan vragen of ie nog een functie x, y of z bij heeft gemaakt of om verbeteringen. Dat kan prima, maar dan eerder periodiek en centraal geregeld.

[Locke_]

Gebruik je al Office 365 en AzureAD? In dat geval zou ik eens kijken of je de gebruikers op een E3 licentie kan zetten. In de E3 licentie zit de mogelijkheid om Intune te gebruiken, wat naar mijn idee veel van jouw uitdagingen gaat oplossen.

Bij ons (+400 werkplekken) werken ze geheel vanuit AzureAD met Intune. We hebben een company portal met de meest gebruikte apps en iedereen is local admin op zijn device. Middels intune policies is het device nog steeds dichtgezet en als je met local admin iets aanpast wat niet mag, zet intune het direct weer terug (als intune je al toegang geeft).

[nst6ldr]

Deveon schreef op donderdag 7 april 2022 @ 15:59:
[...]

SCCM voor 50 werkplekken? Dat is de inrichting echt niet waard en LCM van applicaties is enorm omslachtig, als je zulk budget hebt is de cloud variant van Endpoint Manager veel interessanter (bekend als Intune).

Eens dat SCCM niet evenredig lijkt, maar OP zit met een on-premise domein. Dat zal niet zonder reden zijn, dus cloud oplossingen lijken me niet welkom? @k4sual?

[ Voor 4% gewijzigd door nst6ldr op 07-04-2022 23:56 ]

[BytePhantomX]

Een discussie die ik herken van veel organisaties. Het is moeilijk een balans te vinden tussen gemak van beheer en security in dit geval.

Wat je kan doen is eens vragen wat de analyse of de risico inschatting is dat deze maatregel genomen moet worden. Bij mijn weten schrijft ISO 27001 dit helemaal niet letterlijk voor en is het een interpretatie van iemand geweest. Misschien kun je het risico op een andere manier beheersen.

Er zijn m.i. twee perspectieven hoe je er naar kan kijken. Vanuit de hacker en vanuit governance / compliance. Voor een hacker is local admin zijn prettig. Vaak makkelijker om persistance te creëren. Ze hebben het echter niet nodig. Ook met gewone rechten kun je het netwerk scannen en lateraal bewegen naar een andere server en daar met privilege escalation hun rechten verhogen. Vanuit hackersperspectief vind ik het dan ook een maatregel met beperkt nut.

k4sual schreef op donderdag 7 april 2022 @ 15:21:
... Dit heeft nu als gevolg dat bij iedere update of installatie van wat voor vorm dan ook, de user wordt gevraagd om domain admin credentials in te voeren. Nu worden veel van de applicaties die wij gebruiken helemaal 'kapot' geupdate, en je voelt hem al aankomen met 50 werknemers; je moet dagelijks bij meerdere users langslopen of remote een PC overnemen om de credentials in te voeren. ...

Een hacker vind dit trouwens fantastisch. Verzin iets om dit te forceren op een werkplek die je gehackt hebt en binnen no-time heb je domain admin credentials door een keylogger te gebruiken of cached credentials te achterhalen. Tip: creëer hier een special werkplek admin account voor dat rechten geeft om software te installeren op werkplekken en nergens anders. Gebruik er zeker geen domain admin credentials voor, want dan ben je slechter af dan local admin toestaan. Een domain admin rechten gebruik je alleen op een domain controller, nergens anders en zeker niet op een werkplek.

Vanuit governance en compliance echter een compleet ander verhaal. Heb jij volledig inzicht in wat jouw gebruikers op de systemen installeren? Vaak worden dergelijke systemen ook privé gebruikt en staan er torrent clients etc op. In een zakelijke omgeving vind ik dat zeer onwenselijk. Dat risico kun je echter ook afvangen met goede endpoint tooling die inzicht geven in de geïnstalleerde software en zaken standaard blokkeren. En dan kun je een goede business case maken. Beste management, dit kost ons meer werk en geld. We kunnen dit oplossen door meer mensen, beheer tooling of endpoint tooling. Als security professional zou ik altijd voor het laatste kiezen (denk aan Defender for Endpoint, Eset, SentinelOne, PaloAlto Cortex, etc). Die geeft de meeste bescherming tegen hackers.

[ Voor 24% gewijzigd door BytePhantomX op 08-04-2022 09:03 ]

[k4sual]

nst6ldr schreef op donderdag 7 april 2022 @ 23:55:
[...]


Eens dat SCCM niet evenredig lijkt, maar OP zit met een on-premise domein. Dat zal niet zonder reden zijn, dus cloud oplossingen lijken me niet welkom? @k4sual?

Kleine aanpassing, Hybrid Azure AD*. Werken volledig met Office 365 maar nog wel met een on-premise fileserver, printserver etc. Zijn pas begonnen met Endpoint Manager, en zie al veel mensen hier Endpoint Manager/Intune aanraden.

[Brahiewahiewa]

k4sual schreef op donderdag 7 april 2022 @ 15:21:
...
- Stel dat wij er nu voor kiezen om onze eindgebruikers toch weer local admin rechten te geven op hun PC's, wat zijn hier dan de nadelen/risico's van?...

Een groot nadeel is dat jullie bedrijf bij de eerstvolgende audit, z'n ISO certificaat weer kwijt is. Ik denk maar zo dat jij dat niet aan je manager wilt uitleggen

[DDX]

Brahiewahiewa schreef op vrijdag 8 april 2022 @ 11:52:
[...]

Een groot nadeel is dat jullie bedrijf bij de eerstvolgende audit, z'n ISO certificaat weer kwijt is. Ik denk maar zo dat jij dat niet aan je manager wilt uitleggen

Als je het gewoon netjes beschrijft dat je bepaalde mensen (en met reden erbij) admin rechten geeft.
Kan je prima ISO certificaat verlengen.

[Brahiewahiewa]

DDX schreef op vrijdag 8 april 2022 @ 11:58:
[...]


Als je het gewoon netjes beschrijft dat je bepaalde mensen (en met reden erbij) admin rechten geeft.
Kan je prima ISO certificaat verlengen.

Als je het beschrijft, idd.
Maar dat veronderstelt ook dat de TS dan weet wat er allemaal op zijn netwerk gebeurt.
Dat de TS admin privileges wil uitdelen is niet het probleem. Het is een symptoom van het feit dat de TS geen overzicht over zijn netwerk heeft en voortdurend achter de feiten aan rent.
Dit is overigens niet bedoeld als flame richting TS. Dit is iets wat zijn manager, of zijn manager's manager zou moeten doen

[nst6ldr]

DDX schreef op vrijdag 8 april 2022 @ 11:58:
[...]


Als je het gewoon netjes beschrijft dat je bepaalde mensen (en met reden erbij) admin rechten geeft.
Kan je prima ISO certificaat verlengen.

Wat wil je precies, je bedrijfsvoering veilig en robuust maken of een papieren zekerheid?

Ik kan me niet voorstellen dat de casus van TS als een erg overtuigend 'comply or explain' dilemma overkomt bij een audit, maar meer gemakzucht. Geen aanval overigens, puur vanuit de ogen van een auditor.

[Sissors]

Nu kan ik niet helpen met de specifieke opties, daar zijn genoeg andere hier veel beter in, maar als ik kijk naar mijn werkgever, een multinational met iig de bovengenoemde ISO27001, is afhankelijk van de locatie local admin standaard. Dus ons lukt het iig zonder die certificatie kwijt te raken. En hoewel dat betekend dat ik gewoon zelf programma's kan installeren en updaten, betekend het niet dat ik zomaar alles kan doen, er zijn beperkingen waar mijn local admin account niet omheen komt.

Sinds kort zijn we over naar AdminByRequest. Vraag me niet hoe het precies werkt (je kan hem Googlen), maar we krijgen nu een iets andere popup als je als admin dingen wil doen, worden zaken gelogd, maar we kunnen gewoon programma's blijven installeren.

[nielsn]

Intune is inbegrepen bij een Microsoft 365 Business Premium abonnement en kost € 18,60 per maand. Dat is € 8,10 per maand meer dan een Microsoft 365 Business Standard abonnement of € 97,20 per gebruiker / jaar meer.

Mijn ervaring is dat dit zwaarder weegt dan het gemak voor de beheerder.

[ Voor 24% gewijzigd door nielsn op 09-04-2022 12:04 ]

[Orangelights23]

Hier een ISO 27001 lead auditor.

In het kort: voer een risk assessment uit en bepaal daarna de volgende stappen. De norm geeft je hier alle ruimte voor (in theorie mag je iedereen zelfs hetzelfde account laten gebruiken, zolang dit maar getoetst is een geaccepteerd door het management is). Belangrijkste is dat jouw organisatie een weloverwogen keuze maakt een bepaalt of het risico van het gebruik van dat toe accounts valt binnen de risk appetite.

[Skamba]

Vooropgesteld: ISO 27001 is implementatie-onafhankelijk en dus zal er niks expliciet over local admin rights op Windows instaan.

Waarschijnlijk is een risico gevonden bij veel rechten toekennen aan eindgebruikers, waardoor zij bijv gemakkelijk per ongeluk malware kunnen installeren. Dat is op zich een reëel risico, en ik kan me voorstellen dat daar maatregelen op genomen moeten worden.

Zijn het voor alle gebruikers dezelfde applicaties? Dan kan het handig zijn om iets als centrale patching in te regelen, zoals mensen hierboven ook aangeven.

Zijn de patches nodig of werken de applicaties prima? Dat kun je eventueel ook per applicatie uitzoeken.

Hoe sommige bedrijven er ook mee omgaan is dat by default geen admin rechten te geven, maar op basis van training deze wel te geven aan power users, bijvoorbeeld developers.

Ten slotte zijn er ook tools die tijdelijk verhoogde rechten geven, mits daarvoor afdoende reden is gegeven. Dat soort tools zou je ook kunnen gebruiken.

[Skamba]

Orangelights23 schreef op zondag 10 april 2022 @ 16:27:
in theorie mag je iedereen zelfs hetzelfde account laten gebruiken, zolang dit maar getoetst is een geaccepteerd door het management is

Dat is wat kort door de bocht, want als onderdeel van ISO 27001 moet je ook de doelstellingen van het ISMS bepalen, op basis van interne en externe eisen. Als het ontbreken van een bepaalde beheersmaatregel leidt tot het niet halen van die doelstellingen en dus de interne/externe eisen, kun je deze niet zomaar accepteren.

[Orangelights23]

Skamba schreef op zondag 10 april 2022 @ 16:41:
[...]


Dat is wat kort door de bocht, want als onderdeel van ISO 27001 moet je ook de doelstellingen van het ISMS bepalen, op basis van interne en externe eisen. Als het ontbreken van een bepaalde beheersmaatregel leidt tot het niet halen van die doelstellingen en dus de interne/externe eisen, kun je deze niet zomaar accepteren.

Je slaat heel stappen over als je nu al naar doelstellingen kijkt. Risico assessments is het begin: daarmee bepaal je welke controls je wel en niet wilt hebben. Voor de controls welke je wel wilt hebben, moet je bepalen hoe deze de business ondersteunen. Is dit niet mogelijk, moet het management bepalen wat ze met het risico willen doen.

Ik heb bij vele organisaties 27001 geaudit in binnen en buitenland en werk inmiddels als CISO, ik zie heel veel misvattingen over 27001. Het is zelfs mogelijk om de hele annex a niet te gebruiken, maar bijvoorbeeld CIS controls om risico’s te mitigeren. De vraag van de TO is prima op andere technische wijze op te lossen dan het simpelweg verbieden, wat in eerste instantie gedacht wordt omdat dit een ISO control zou zijn.

[Skamba]

Orangelights23 schreef op zondag 10 april 2022 @ 17:42:
[...]


Je slaat heel stappen over als je nu al naar doelstellingen kijkt. Risico assessments is het begin: daarmee bepaal je welke controls je wel en niet wilt hebben. Voor de controls welke je wel wilt hebben, moet je bepalen hoe deze de business ondersteunen. Is dit niet mogelijk, moet het management bepalen wat ze met het risico willen doen.

Ik besef me dat ik hiermee offtopic ga, maar ik vind het toch belangrijk om even een aantal zaken helder te hebben, zeker omdat mensen nogal vanuit Google op GoT terechtkomen.

Volgens mij verwar je beheersdoelstellingen (control objectives), die gekoppeld zijn aan een beheersmaatregel met je doelstellingen t.a.v. het ISMS (intended outcomes of the ISMS). Het bepalen daarvan komt zeer zeker voor het risico-assessment.

De belangrijkste relevante paragraaf daarvoor is het eerste gedeelte van 6.1.1:
When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to:
a) ensure the information security management system can achieve its intended outcome(s);

Waarbij onder 4.2 de eisen van geïnteresseerde partijen (interested parties) zijn bepaald. Oftewel: je kan niet zomaar als management alle risico's accepteren als onderdeel van je risicomanagementstrategie, omdat je de eisen van andere partijen daarin mee moet nemen.

Het is een bekend fabeltje dat je ISO 27001 gecertificeerd zou kunnen zijn door alle risico's te accepteren. Dat loopt in de praktijk stuk op bovenstaande eisen - er is geen bedrijf waarvan de geïnteresseerde partijen niet als eis hebben dat een bepaald minimaal niveau van maatregelen geïmplementeerd is.

Ter achtergrond: Ik heb jarenlang ISO 27001 Lead Auditor en Lead Implementer trainingen gegeven. Daarnaast was ik lead auditor voor multi-site certificates met >100 locaties in scope.

[eamelink]

Dus de juiste stap is kijken waarom deze maatregel gekozen is. Vanuit ISO27001 is dit geen eis. Het kan dus een directe eis zijn vanuit een interested party, maar het kan ook een gekozen risico verminderende maatregel zijn. Dan is het zaak om te kijken welk risico hiermee verkleind wordt. Wellicht kan dat ook op een andere manier bereikt worden

[nst6ldr]

...even los van risico acceptatie of niet: de 'gewenste' situatie - met of zonder certificering - is sowieso wachten op ellende. Vroeg of laat ben je aan de beurt, en dan kan je hooguit dat certificaat gebruiken om je tranen weg te vegen omdat er 2 ton wordt gevraagd voor de sleutel tot alle bestanden van je bedrijf. En dat terwijl er volgens mij echt wel ruimte is voor een betere AD inrichting.

[NLKornolio]

Implementeer LAPS, hernoem gelijk ook het local admin account. Geef het local admin password en reset het dan weer.

Qua security als je de CIS controls nahoudt zorg je dat local admin accounts niet via het netwerk kunnen inloggen alleen lokaal waardoor risico meevalt dan alleen lokaal wat slopen.

Zorg dan wel dat je pash the hash ook oplost zodat lokaal higher elevated credentials kan hacken. Voor deze oplossing niet van toepassing maar wel iets om over na te denken.

[Orangelights23]

Skamba schreef op zondag 10 april 2022 @ 19:58:
[...]

Ik besef me dat ik hiermee offtopic ga, maar ik vind het toch belangrijk om even een aantal zaken helder te hebben, zeker omdat mensen nogal vanuit Google op GoT terechtkomen.

Volgens mij verwar je beheersdoelstellingen (control objectives), die gekoppeld zijn aan een beheersmaatregel met je doelstellingen t.a.v. het ISMS (intended outcomes of the ISMS). Het bepalen daarvan komt zeer zeker voor het risico-assessment.

De belangrijkste relevante paragraaf daarvoor is het eerste gedeelte van 6.1.1:
When planning for the information security management system, the organization shall consider the issues referred to in 4.1 and the requirements referred to in 4.2 and determine the risks and opportunities that need to be addressed to:
a) ensure the information security management system can achieve its intended outcome(s);

Waarbij onder 4.2 de eisen van geïnteresseerde partijen (interested parties) zijn bepaald. Oftewel: je kan niet zomaar als management alle risico's accepteren als onderdeel van je risicomanagementstrategie, omdat je de eisen van andere partijen daarin mee moet nemen.

Het is een bekend fabeltje dat je ISO 27001 gecertificeerd zou kunnen zijn door alle risico's te accepteren. Dat loopt in de praktijk stuk op bovenstaande eisen - er is geen bedrijf waarvan de geïnteresseerde partijen niet als eis hebben dat een bepaald minimaal niveau van maatregelen geïmplementeerd is.

Ter achtergrond: Ik heb jarenlang ISO 27001 Lead Auditor en Lead Implementer trainingen gegeven. Daarnaast was ik lead auditor voor multi-site certificates met >100 locaties in scope.

We praten aardig langs elkaar heen, blijkt. Ik heb jarenlang wereldwijd ISO implementaties gedaan en beheerd en ook flink wat jaren als auditor gewerkt, ik weet genoeg van de norm om het te kunnen reciteren maar laten we niet verder op dit punt in gaan, ik wil graag de ruimte bieden om antwoorden te laten ontstaan (zit zelf in een ISO audit van vier weken dus weinig tijd om te kunnen reageren ).

[laurens0619]

Bijzondere maar helaas herkenbare situatie

van:
- gebruikers zijn local admin maar er wordt geen domain admin credential regelmatig ingevoerd en software is gepatched

Naar:
- gebruikers zijn geen local admin, domain admin credentials worden regelmatig ingevoerd en software is niet op to date

Als deze aannames kloppen dan ben je 10 stappen achteruit ipv vooruit. :((

Het meest teleurstellende is dat, zoals eerder aangehaald, local admin rechthalen minder zaligmakend is dan veel mensen denken. Je hebt in windows genoeg vrijheid als hacker onder userrechten.

Echter als ik een top 5 controls zou moeten voorstellen bij een mkb zonder risico assessment of context dan zou het zijn
- auto updates aan
- defender atp installeren en dashboard monitoren, niet alleen voor inc maar vooral vuln management
- defender atp tamper protection aan
- laps installeren
- zoveel mogelijk asr rules aan (vooral rondom macro)

Gaat je netto veel meer opleveren dan admin rechten.

Daarbij zeg ik niet dat je admin rechten niet moet ontnemen want dat is een terechte best practice. Maar alleen als de rest ook netjes in place is