Să presupunem că aveți o organizație care în prezent nu folosește procese de control al schimbărilor, doar ticketing de bază.
Doriți să implementați zero trust pe 3-5 site-uri.
Cum procedați pentru implementare?
Când am mutat un birou, echipa noastră de rețea a prioritizat zero trust peste verificarea funcțiilor.
Practic, au spart patch-urile de securitate și alte servicii în întreaga organizație.
Ei se dublază în zero trust și spun că 1-2 administratori de sistem trebuie să mapeze totul în mediu pentru ei înainte de a putea continua, dar vor ca noi să mapăm totul manual prin documentație, fără instrumente automate de descoperire etc.
Este ceva comun?
Sugestii pentru metode mai bune de implementare?
Cum implementați zero trust?
Totul depinde de cultura organizației, banda disponibilă și tipul de Zero Trust pe care îl vizați. Zero Trust nu înseamnă să distrugi totul—este pur și simplu despre verificarea fiecărei cereri de acces. Începeți cu o evaluare solidă - modelul de maturitate Zero Trust al CISA este o referință excelentă - apoi mapați rețeaua, documentați suprapunerile VLAN / medii de rețea și înțelegeți unde utilizatorii au acces multi-VLAN și de ce. Dacă ați făcut deja temeinic cercetarea și doriți să accentuați segmentarea, implementați-o etapă cu etapă—păstrați cele mai critice procese pentru schimbările majore astfel încât să puteți construi cazul pe drum.
Țineți cont că majoritatea problemelor de implementare provin din probleme de continuitate a afacerii, limitări de bandă a echipei și necesitatea educației continue. Politicile interne pot impulsiona proiectele sau le pot face să eșueze, așa că stabiliți așteptările devreme și comunicați clar cu stakeholderii. În experiența mea, o abordare etapizată, metodică, care echilibrează măsurile de securitate dure cu realitățile operaționale, este cea mai bună cale de a ajunge la o postură robustă de Zero Trust fără a transforma mediul într-un haos.
Unul face de obicei o justificare pentru o schimbare arhitecturală în etapa de valoare propoziție, nu ulterior. Nu pot vedea conținutul postului din orice motiv, dar recomand să aveți totul în scris și aprobat de șefii dvs. Numele jocului este să vă acoperiți și să aveți o procedură clară de rollback testată și pregătită.
Mi-aș imagina că există un lider sau o echipă specifică care conduce această inițiativă? Cu un plan de proiect real? Dacă nu, cred că va fi foarte dificil de realizat.
Vorbind ca cineva care a văzut un proiect ZTA eșuând spectaculos într-o organizație mare și care a fost implicat într-unul de succes.
Implementarea ZTA durează ani și trebuie să fie iterativă. Nu poți doar să „te blochezi complet” și să limitezi totul odată; nimeni nu cunoaște în detaliu suficiente despre mediul lor pentru a realiza acest lucru fără a-și afecta afacerea. Întotdeauna vor exista fluxuri de date, dispozitive, limitări ale hardware-ului/software-ului legacy și alte lucruri care te vor surprinde.
Dar vestea bună este că fiecare pas pe care îl faci spre ZTA te face mai sigur. Gândește-te la asta ca la reducerea scope-ului și a nivelului de încredere, pas cu pas. Pe măsură ce se întâmplă asta, vei vedea multe beneficii, în afară de securitate. De exemplu, este inevitabil ca procesele tale de gestionare IT să se îmbunătățească (pentru că dacă nu, vei distruge totul în mod regulat). Vei descoperi probleme în mediul tău pe care nu le știai și care îți cauzau durere, și vei putea să le repari în proces.
Este ușor să critici de pe margine: Nu poți realiza zero trust fără să înțelegi cerințele de comunicare. Asta aproape că pare ca echipa de rețea forțează cele mai bune practici pentru a documenta și înțelege sistemele din mediul respectiv.
Disclaimer: Sunt obosit, și dacă nu postez asta acum, niciodată nu va ieși din drafturi. Așa că, toți, ignorați sau citiți-l știind că nu l-am verificat gramatical sau nu e complet coerent… Baftă tuturor…
O mulțime de discuții bune aici, și pare că ați primit deja sfaturi solide!
Un singur lucru de adăugat: Încercați să explicați acest lucru echipei voastre de securitate/rețea. Ei trebuie să fie abilitatori, nu dictatori. Rolul nostru în securitate/rețea este să menținem afacerea funcțională fără perioade mari de nefuncționare. Dacă închid organizația pentru o zi sau două și ne costă milioane… ce dracu am realizat? În acel moment, am putea la fel de bine să plătim răscumpărarea când suntem răpiți de ransomware. Îmi plac securitatea și rețeaua, dar există foarte puține scenarii în care „ciocanul” trebuie să cadă—și dacă acesta este muntele pe care echipa voastră vrea să morți… lasă-i să o facă.
Rant final. Așa am abordat acest lucru în rețeaua noastră:
Când Windows Server 2012 se apropia de sfârșitul vieții (și am vrut să migrăm la 2016), am demarat un Proiect de Modernizare a Securității. Orice server sau aplicație nouă se pune într-o zonă dedicată specifică serviciului respectiv. De exemplu, dacă ai nevoie de un cluster de servere ELK, vom lăsa toate serverele din acea zonă să comunice liber. Dar dacă ceva trebuie să vorbească în afara zonei? Trebuie să ai un motiv foarte bun—și să specifici portul și destinația.
Așa cum au spus și alții, Zero Trust este o metodologie, nu un produs. Instrumentele ajută, dar nu sunt strict necesare. Pentru mine, totul se reduce la: „Oferă acces doar acolo unde este absolut necesar, punct.” Cel mai mare obstacol? Oamenii nu înțeleg propriile aplicații. Când se întâmplă asta, vor trebui să înceapă să învețe—sau poate va trebui să găsiți persoane mai potrivite.
Baftă cu echipele voastre de securitate și rețea. Respect misiunea lor, dar riscă să piardă sprijin dacă continuă această abordare.