Privileged Access Workstation aka PAW
Conceptul de Privileged Access Workstation sau Secure Admin Workstation sau PAW e ceva destul de frecvent discutat in ultimii ani si deja vad multe companii ce au inceput sa implementeze modelul.
Totusi, multe din elementele din acest subiect sunt “de bun simt” pentru un admin cu experienta. Plus ca nu sunt chestii chiar atat de noi. Conceptul de administration workstation era discutat chiar de pe vremea Windows 2000/2003. Inca mai tin minte documentatia de Securing/Design de la Windows 2003 unde era recomandat sa folosesti credentialele de administrare doar pe statii dedicate si erau detaliate pana si GPO-urile pe care sa le aplici. Deci nu e ceva chiar atat de nou, pentru cei cu vechime e chiar boring.
Dar sa incercam sa discutam putin subiectul. De ce o statie dedicata pentru administrare?
Pentru a diminua riscul ca un atacator sa compromita contul unui admin, printr-un cont de user normal deja compromis (exploituri web, email, executabile, keyloggers, etc).
Deci in conceptul de PAW, discutam de un sistem dedicat folosit pentru administrare. Asta inseamna ca orice persoana cu rol de admin va folosi doua sisteme pentru activitatile de zi cu zi in companie. Un sistem pentru regular tasks (web, email, office apps, LOB apps etc) si inca un sistem unde se va loga folosind credentialele de admin. Si pentru a nu fi compromise aceste credentiale, acestea nu vor avea drept de logon pe sistemele unde un user normal se poate loga (dupa cum am spus, riscul ca un user normal sa fie compromis este mult mai mare).
Separand aceste doua taskuri – admin tasks & regular user tasks, punem o bariera intre interactiunea celor doua si diminuam riscurile de escalare a privilegiilor.
Si in mare ar fi doua variante de implementare:
1. Doua statii fizice. Una pentru taskuri normale si alta pentru cele de admin. Avantajul este separarea clara intre cele doua; cele doua sisteme nu interactioneaza in nici un fel. Dezavantaje: destul de multe. Nimeni nu vrea sa foloseasca doua seturi de tastaturi si sa se mute de la un monitor la altul, sau sa care doua laptopuri dupa el.
2. Partajarea unui singur sistem folosind tehnologiile de virtualizare existente. Avantajul fiind aici in usurinta de utilizare (comparand cu primul scenariu). Dezavantaj: unii ar spune ca daca exista o vulnerabilitate in tehnologia de virtualizare, un atacator s-ar putea folosi de aceasta vulnerabilitate sa compromita intreaga statie sau sa acceseze date din partitia administrativa. Scenarii pot fi foarte multe aici, dar important este ca pana acum tehnologiile de virtualizare au fost destul de sigure si as spune ca riscul este destul de mic.
Daca pentru primul scenariu, setup-ul este simplu, doua sisteme fizice separate, in al doilea scenariu poti sa ai nenumarate variante. Nu o sa incerc sa le descriu pe toate, doar o sa va dau cateva idei si o sa mentionez regula de baza dupa care trebuie sa va ghidati cand setati acest model.
Nota: In continuare o sa denumesc statia administrativa PAW si statia userului standard UW.
Intotdeauna directia de acces trebuie sa fie dinspre PAW catre UW si nu invers. Si vad greseala asta facuta foarte des chiar acolo unde s-a incercat implementarea unui astfel de model. Daca vrei cu adevarat sa implementezi o astfel de solutie, respecta aceasta regula de baza.
Exemple de scenarii gresite:
– UW instalat direct pe hardware in care ruleaza hypervizor si un PAW VM. Admin-ul isi face taskurile normale din acest host OS, si cand vrea sa isi acceseze contul de admin, porneste PAW VM-ul si se conecteaza la el. In acest scenariu daca acel host OS este compromis, automat si PAW-ul va fi, sau credentialele administrative pentru ca sunt introduse direct de la tastatura host-ului (un keylogger in host, compromite absolut tot)
– UW instalat direct pe hardware si PAW remote (VDI, Jump server, etc). La fel ca si in primul scenariu, tot ce tastezi, trece prin UW (cu acces la internet si foarte expus). Bineinteles ca scenariul este clar mult mai bun decat daca te-ai loga pe acelasi sistem cu ambele seturi de credentiale, dar se poate si mai bine.
Exemplu de scenarii ok:
– Host OS cu hypervisor in care ai VM-uri pentru diversele roluri pe care ai. VM pentru UW si alt VM pentru PAW. Separare clara intre cele doua, nu se acceseaza unul pe celalalt. Protectia este oferita de hypervizor. OS-ul de pe host este folosit doar pentru a te conecta la VM-uri.
– PAW instalat direct pe hardware + hypervizor. UW instalat ca VM de pe PAW. Din sesiunea de logon de pe PAW se poate accesa UW. Chiar daca UW-ul este compromis, nici macar un keylogger nu poate afecta sesiunea de pe PAW. (cu toate ca acest scenariu este recomandat de MS, eu il prefer pe primul; prefer sa folosesc contul de admin numai cand este nevoie, nu sa trec prin sesiunea de admin doar ca sa ma conectez la UW).
Si de aici poti sa faci o gramada de scenarii, cu VDI, thin clients, jump servere etc. Bineinteles ca exista si alte detalii, gen hardware-ul folosit, OS, procedura de hardening, metode de enforcement pentru a limita folosirea credentialelor doar pe anumite sisteme, monitorizare. Dar subiectul este vast si am vrut doar sa punctez una dintre cele mai frecvente greseli facute.
Microsoft a facut o super treaba in ultimii ani si a publicat documentatie foarte bine pusa la punct pe aceasta tema:
https://msdn.microsoft.com/en-us/library/mt186538.aspx