Wie op zoek is naar discussie doet op populaire online-forums de oproep om lokale admin-rechten van elke gebruiker in de organisatie te verwijderen. Is verhoogde rechten verwijderen van endpoints van 'gewone' zakelijke gebruikers voor veel security-professionals nog logisch, lokale beheerdersrechten volledig elimineren is dat zeker niet. En toch zijn er argumenten om het wel te doen.
Lokale admin-rechten zijn ideale entreedeuren voor kwaadwillenden en een gemiddelde werknemer heeft die rechten helemaal niet nodig. Weg ermee dus. Maar hoe zit het met beheerders en databasebeheerders, de helpdesk, het infrastructuuronderhoudsteam en backup-operators? Zij hebben toegang op hoog niveau nodig om hun werk te doen, en een beveiligingsteam heeft geen tijd of middelen om handmatig extra rechten toe te kennen.
Allemaal waar, maar het betekent niet dat geprivilegieerde gebruikers lokale beheerders moeten zijn. Geen enkele gebruiker hoeft een lokale admin zijn. Hieronder worden 29 redenen gegeven waarom – en dit is zeker geen volledige lijst. In het kort komt het neer op: met volledige admin-rechten heeft zelfs de meest goedbedoelende, gewetensvolle werknemer te veel controle over de digitale omgeving van een organisatie, waardoor kritieke gegevens en systemen (zelfs bestaande beveiliging) in gevaar komen.
Frustratie
Iedereen laten werken onder standaard-gebruikersaccounts zal een positieve impact hebben op de security, maar het beperken van de rechten van beheerders leidt tot aanzienlijke frustratie en mogelijk juist meer werk voor security-admins. Sommige deelnemers aan de discussie gaan zelfs zover dat ze zeggen dat het schrappen van lokale admin-rechten een organisatie meer kwaad dan goed doet. Maar dat zijn ook mensen die hun dag door hebben gebracht met het op afstand aansturen van computers van collega’s om een lettertype of een printer te installeren, een applicatie te updaten of de tijdzone te veranderen. Of misschien probeerden ze zich op te dringen aan deze collega’s en moesten ze uiteindelijk toegeven en de lokale admin-rechten teruggeven.
Dit wordt opgelost door een veelzijdige endpoint-privilegemanager die lokale admin-rechten kan verwijderen en vervolgens, op basis van beleid, rechten voor bepaalde toepassingen of taken op een transparante manier kan verhogen, zodat een gebruiker nooit een prompt ziet of it om hulp hoeft te vragen. En als ze een speciaal geval hebben, kunnen gebruikers om verruiming van rechten vragen, die is goed te keuren zonder ooit op afstand contact met het apparaat te moeten maken. Aan de achterkant is een effectieve endpoint-privilegemanager zelfs geïntegreerd met een it-ticketingsysteem voor soepele workflows en snelle verruimingen van de rechten.
Fijnmazige
Endpoint privilege managers zijn een cruciaal onderdeel van de moderne endpointsecuritystack, maar niet alle oplossingen zijn gelijk. Een best-of-breed endpointprivilege-manager stelt een organisatie in staat om lokale admin-rechten te verwijderen en least privilege af te dwingen; blokkeert ransomware door toepassingsmachtigingen strikt te controleren op basis van fijnmazige, voorwaardelijke bedrijfspolicies, en beschermt tegen diefstal van inloggegevens. Bovendien wordt de gebruikerservaring verbeterd door de juiste mensen en toepassingen op het juiste moment de juiste toegang tot de juiste bronnen te geven. Hierbij wordt het voldoen aan audit- en compliance-eisen gemakkelijker door policies af te dwingen. Endpoint-privilegemanagers beschermen dus niet alleen, ze voegen, na wat eerste gefrustreerde reacties, ook al snel waarde toe.
Voor de handelingen op de lijst zijn niet altijd beheerdersrechten nodig. En ook al halen we die weg, dan nog zullen sommige aanvallen uiteindelijk langs sommige endpoint-defense-in-depth-lagen glippen. Maar een assume-breach uitgangspunt, het elimineren van lokale admin-rechten over de hele linie en het afdwingen van least privilege op het endpoint (en andere plekken) maken het voor aanvallers zo veel moeilijker om hun doel te bereiken dat een meerderheid elders zal zoeken.
Mogelijkheden
De mogelijkheden van een gebruiker met lokale admin-rechten (of een aanvaller die zich voordoet als die gebruiker):
- Boot en hardware-configuraties wijzigen (apparaten in-/uitschakelen, cpu en geheugen voltage en frequenties wijzigen);
- Opslagvolumes wijzigen of verwijderen;
- Malware-technieken zoals code-injectie en dll-hijacking radicaal vereenvoudigen;
- Gemakkelijk persistence krijgen op een machine met het register volledig open voor analyse en wijziging;
- Journaling uitschakelen, events wijzigen of wissen;
- Backup-agents uitschakelen of backup-configuraties wijzigen, en een lokale backup-kopie wissen;
- Instellingen voor schaduwkopieën wijzigen of schaduwkopieën kopiëren (om eerder ‘gewiste’ gegevens te exfiltreren);
- Gebruikers wijzigen/toevoegen, administratieve gebruikers toevoegen of administratieve gebruikers verbergen uit het aanmeldingsmenu;
- Toegang tot de gegevens van elke gebruiker op de machine en verandering van de eigenaren van bestanden en mappen;
- Master boot record () van de harde schijf versleutelen (ook bekend als vijftien seconden durende, volledige schijf-ransomware-versleuteling);
- Bestaande beveiligingsoplossingen voor endpoints uitschakelen of herconfigureren;
- Netwerkinstellingen wijzigen, trust-zones toevoegen, tunnels opzetten of verkeer omleiden;
- Het domeinnaamsysteem (dns) wijzigen/kapen of gegevens exfiltreren via dns-verzoeken;
- Browserinstellingen wijzigen of browserextensies toevoegen;
- Toegang krijgen tot elk secret dat op de machine is opgeslagen (in Windows-credentialproviders, in de browser, in Putty, in FileZilla of elk ander programma dat credentials opslaat);
- Toegang krijgen tot en wijzigen van certificaatopslag, vertrouwensketens wijzigen en alle beveiligde communicatie ontsleutelen;
- Living off the land (luxueus);
- Geheugeninhoud openen, analyseren en wijzigen;
- Beveiligingsdiensten gebruiken om code-uitvoering te verkrijgen in de local security authority server service, die ook is te gebruiken om wachtwoord-hashes en Kerberos-tickets te extraheren;
- Elke niet-kwaadaardige administratieve tool installeren en een arsenaal aan goedaardige tools inzetten (die in de verkeerde handen de ‘ultieme-aanvallertoolkit’ worden) zonder de antivirus te activeren;
- Cryptominer-malware installeren om de bronnen van de machine over te nemen en te gebruiken voor het illegaal ontginnen van cryptocurrency;
- Ingebouwde of externe hardware-trackers inschakelen om apparaten overal ter wereld te lokaliseren;
- User access control omzeilen en/of uitschakelen;
- Stuurprogramma’s, versies en libraries downgraden of het gebruik van bekende kwetsbare protocollen en programma’s af dwingen;
- Firmware flashen naar aangesloten apparaten (de led van een camera uitschakelen of gewijzigde firmware in een plc laden);
- Toegang krijgen tot beveiligingstokens en encryptiesleutels;
- Air-gaps overbruggen om toegang te krijgen tot kritieke systemen voor operationele technologie;
- Toegang krijgen tot scada (Supervisory Control and Data Acquisition)- controlepanelen voor kritieke infrastructuur, en vervolgens hardware-parameters wijzigen om veiligheidssensoren uit te schakelen of hardware-resonantie te veroorzaken;
- En tenslotte een eigen avontuur kiezen: installeren, verwijderen, toegang krijgen, lezen, exfiltreren, onderscheppen, uitpakken, analyseren, dumpen, versleutelen, herconfigureren, ontladen, laden, inschakelen, uitschakelen, uitvoeren of op afstand uitvoeren, veroorzaken, forceren, omdraaien, wissen, knoeien met en vernielen, terwijl ze zich ook verbergen, verstoppen, zich voordoen, meekijken, luisteren, spioneren, leren en voorbereiden.
Een “best-of-breed endpointprivilege-manager” die “na wat eerste gefrustreerde reacties, ook al snel waarde toe” voegt.
zucht.
Daar sta je dan met je T-shape in je zelfsturende team tickets in te dienen om asjeblief ergens een bestandje in een folder te kunnen zetten.
Ik kijk graag uit naar weer een artikel in computable over gemotiveerd personeel, hoe te krijgen en hoe te houden 🙂
Wat betreft least privilege op het endpoint (en andere plekken) moet het wel werkbaar blijven want gefrustreerde reacties zijn ook een risico. Onwerkbare omgevingen leiden tot een exodus van de data, endpoint-privilegemanagers leggen focus nog teveel op systemen als ik kijk naar veel voorkomende datalekken.
Di is naar mijn mening een rode haring. Security breaches (elevaties) worden veroorzaakt door hackers die al met administrator bevoegdheid lopende processen beïnvloeden, om foute dingen te doen. Zoals bij Log4J. Het al dan niet aanwezig zijn van een lokaal administrator account (gebruiker) heeft daar niets mee van doen. Hackers kunnen namelijk niet inloggen als lokale beheerder. Als dat toch kan, bijvoorbeeld omdat lokale-beheerder-wachtwoorden uitgelekt zijn, dan heb je een probleem van een heel andere orde.
Je praat over 29 redenen waarom het niet nodig is. Ik mis deze wel in je verhaal. Wat ik zie is een lijst van dingen die je kan doen als je admin bent. Dat is samen 1 reden, je kan het systeem zo aanpassen dat je jezelf kan verstoppen. Kwaad doen dus.
Ik heb in meerde situatie meegemaakt dat gebruikers hier om vroegen. Vaak is het zo dat ze niet 24×7 admin willen zijn, maar op een cruciaal moment de rechten nodig hebben om iets te doen. Wat? Dat is vaak van te voren nog niet vast te stellen, anders kun je het automatiseren. Juist in onverwachte situatie wil een gebruiker iets kunnen.
Nu zit er ook een hoop tussen guest en admin en is het zeker goed dit te onderzoeken. Mijn persoonlijke ervaring is dat je er slimmer aan doet ze een lokaal admin account te geven. Dit is niet hun dagelijkse account, maar een speciaal account om iets te doen waarvoor admin rechten nodig is. Verder goed uitleggen wat de risico’s zijn en deze bij je gebruiker leggen of zijn manager. Dit leid over het algemeen wel tot de juiste situatie.