Evaluarea securității cibernetice și modelul de încredere zero Securitate cibernetică


În ultimii ani, conceptul de arhitectură „încredere zero” a trecut printr-o serie de faze evolutive. A trecut de la a fi noua modă fierbinte, la a fi banal (în mare parte datorită unui potop de marketing de la cei care doresc să încaseze trendul), să treacă, iar acum s-a stabilit în ceea ce probabil ar fi trebuit să fie întotdeauna totul împreună: o opțiune de securitate solidă, lucrătoare, cu avantaje și dezavantaje discrete, observabile, care poate fi încorporată în abordarea de securitate a organizației noastre.

Încrederea zero, așa cum sugerează și numele, este un model de securitate în care toate activele – chiar și punctele finale gestionate pe care le furnizați și rețelele locale configurate de dvs. – sunt considerate ostile, de neîncredere și potențial deja compromise de atacatori. În loc de modele de securitate moștenite care diferențiază un interior „de încredere” de unul extern de încredere, încrederea zero presupune în schimb că toate rețelele și gazdele sunt la fel de nedemn de încredere.

Odată ce faceți această schimbare fundamentală în ipoteze, începeți să luați diferite decizii cu privire la ce, cui și când să aveți încredere și metodele de validare acceptabile pentru a confirma o cerere sau o tranzacție este permisă.

Ca mentalitate de securitate, aceasta are avantaje și dezavantaje.

Un avantaj este că vă permite să aplicați strategic resurse de securitate acolo unde aveți cel mai mult nevoie; și crește rezistența la mișcarea laterală a atacatorului (deoarece fiecare resursă trebuie să fie ruptă din nou dacă ar stabili un cap de plajă).

Există și dezavantaje. De exemplu, aplicarea politicilor este necesară pentru fiecare sistem și aplicație, iar componentele vechi vechi construite cu diferite ipoteze de securitate s-ar putea să nu se potrivească bine, de ex. că rețeaua internă este de încredere.

Una dintre cele mai potențiale dezavantaje problematice are legătură cu validarea posturii de securitate, adică în situațiile în care modelul de securitate necesită revizuirea de către organizații mai vechi, mai mult orientate către moștenire. Dinamica este nefericită: aceleași organizații care sunt susceptibile să găsească modelul cel mai convingător sunt aceleași organizații care, adoptându-l, sunt susceptibile să se înființeze pentru verificarea provocărilor.

Validarea și minimizarea expunerii

Pentru a înțelege dinamica pe care o înțelegem aici, este util să luăm în considerare care este următorul pas logic odată ce încrederea zero a fost adoptată. Mai exact, dacă presupuneți că toate punctele finale sunt potențial compromise și că toate rețelele sunt probabil ostile, o consecință naturală și logică a acestei presupuneri este de a minimiza unde pot merge datele sensibile.

S-ar putea, de exemplu, să decideți că anumite medii nu sunt suficient de protejate pentru a stoca, prelucra sau transmite date sensibile altele decât prin canale foarte definite, cum ar fi accesul HTTPS autentificat la o aplicație web.

În cazul în care se face o utilizare intensă a serviciilor cloud, este destul de logic să decidem că datele sensibile pot fi stocate în cloud – subiect, desigur, să acceseze mecanismele de control care sunt construite în mod explicit în acest scop și care au măsuri de securitate și operaționale personal pe care nu vă puteți permite să-l implementați sau să-l întrețineți doar pentru propria utilizare.

De exemplu, spuneți că aveți o organizație ipotetică mai tânără în piața medie. Prin „mai tânăr”, vrem să spunem că poate au trecut doar câțiva ani de la înființarea organizației. Să presupunem că această organizație este „cloud native”, adică externalizată 100% pentru toate aplicațiile de business și arhitecturată în întregime în jurul utilizării cloud-ului.

Pentru o organizație ca aceasta, încrederea zero este convingătoare. Deoarece este 100% externalizat, nu are centre de date sau servere interne și păstrează doar cea mai mică amprentă tehnologică locală. Această organizație ar putea cere în mod explicit ca nicio informație sensibilă să nu poată „trăi” pe punctele finale sau în rețeaua lor de birou. În schimb, toate aceste date ar trebui să se afle în subsetul de servicii cloud cunoscute și definite, care sunt aprobate în mod explicit în acest scop.

Acest lucru înseamnă că entitatea își poate concentra toate resursele pe consolidarea infrastructurii cloud, servicii de poartă astfel încât toate accesul (indiferent de sursă) este protejat într-un mod robust și deprioritizează lucruri precum securitatea fizică, întărirea rețelei interne (presupunând că există chiar și unul), implementarea controalelor de monitorizare internă, etc. Presupunerea unui proces sârguincios, de lucru, este urmată pentru a asigura utilizarea componentelor cloud, o astfel de abordare poate ajuta la concentrarea asupra resurselor limitate.

Cu toate acestea, exemplul de organizație de mai sus nu funcționează în vid – nici o organizație nu funcționează. Funcționează cu clienții, conduce în procesul de vânzare, parteneri de afaceri și mulți alții. Deoarece organizația este una mai mică, mulți dintre clienții săi ar putea fi organizații mai mari – potențial clienți cu cerințe stricte privind securizarea furnizorilor externi de servicii și validarea securității acestora. Poate că are obligația de reglementare de a face acest lucru, în funcție de sectorul în care se află. Acum, unii dintre acești clienți ar putea fi externalizați complet, dar majoritatea nu vor fi – vor avea aplicații vechi, constrângeri unice, cerințe specializate și alte activități motive pentru care nu pot susține un model complet extern.

Ceea ce rezultă este adesea o discuție perfect înțeleasă, dar totuși contraproductivă, în scopuri încrucișate între organizația care efectuează evaluarea (clientul potențial) și cel care este evaluat (furnizorul de servicii). Un furnizor de servicii, de exemplu, ar putea argumenta în mod rezonabil că controalele de securitate fizică (pentru a alege doar un exemplu) nu intră în domeniul de aplicare în scopul evaluării. Ar putea argumenta acest lucru pe baza faptului că singurele controale de securitate fizică care contează sunt cele de la furnizorii de cloud pe care îi angajează, întrucât, la urma urmei, acesta este singurul loc în care datele sunt permise să locuiască.

Pe de altă parte, clientul ar putea, de asemenea, în mod rezonabil să-și facă griji cu privire la aspectele de securitate fizică care țin de mediul furnizorului de servicii. De exemplu, accesul vizitatorilor la facilități în care datele despre clienți ar putea fi vizualizate pe ecran, chiar dacă datele nu sunt stocate acolo. S-ar putea imagina un scenariu, de exemplu, în care un vizitator neautorizat la birou ar putea „naviga pe umăr” date pe măsură ce sunt introduse pe ecran de un utilizator legitim.

O conversație ca cea de mai sus, chiar și atunci când nu devine controversată, este încă suboptimă pentru ambele părți implicate. Din punctul de vedere al furnizorului de servicii, acesta încetinește procesul de vânzare și elimină timpul departe de inginerii care altfel s-ar concentra pe dezvoltarea produselor. Totuși, din punctul de vedere al potențialului client, îi face să fie nervoși cu privire la sursele potențiale de risc nedeclarat – în timp ce generează în același timp stări de rău cu partenerii de afaceri interni dornici să se angajeze la serviciu și care ar dori să vadă verificarea rapidă.

Strategii de principiu

Deci, întrebarea devine: Cum comunicăm în mod eficient un model de încredere zero dacă dorim să îl folosim în acest mod? Dacă validăm o astfel de abordare, cum putem răspunde la întrebările corecte, astfel încât să putem ajunge rapid la o hotărâre și (în mod ideal) să permitem utilizarea serviciului în afaceri? Se pare că există câteva abordări pe care le putem folosi. Niciunul dintre ei nu este știință de rachete, dar necesită să aveți empatie – și să faceți o treabă – pentru a sprijini.

Din punct de vedere al furnizorului de servicii, există trei principii utile de reținut: 1) să fie viitoare, 2) să demonstreze validarea ipotezelor dvs. și 3) să susțineți afirmațiile cu documentație.

Prin „viitoare” mă refer la disponibilitatea de a partaja informații dincolo de ceea ce ar putea cere un client. Dacă furnizați un SaaS cloud ca în exemplul de mai sus, acest lucru ar putea însemna că sunteți dispus să partajați informații dincolo de setul specific de articole solicitate de client. Acest lucru vă permite să „generați” informații chiar și până la punctul de a beneficia de livrări standard. De exemplu, ați putea lua în considerare participarea la CSA STAR registru, pregătiți artefacte standard de colectare a informațiilor, cum ar fi CSA CAIQ, Evaluări partajate Evaluarea controlului standardizat SIG, sau Programul HITRUST de evaluare a terților în spațiul medical.

Al doilea principiu, care demonstrează validarea, înseamnă că ați validat ipotezele care au intrat în modelul dvs. de securitate. În exemplul de mai sus, acest lucru înseamnă că am putea sprijini ipoteza „nu există date stocate intern” cu validarea acestora. Un evaluator de la un client este mult mai probabil să creadă declarația dacă se folosește un control precum DLP pentru validare.

Ultimul punct al existenței documentației înseamnă documentarea modelului pe care îl susțineți. De exemplu, dacă puteți furniza un document arhitectural care să descrie abordarea dvs.: de ce îl utilizați, analiza riscurilor pe care ați efectuat-o în prealabil, controalele în vigoare etc. Faceți o copie de rezervă cu o politică definită care stabilește principiile și așteptările de securitate .

Din partea evaluatorului, există într-adevăr un singur principiu, acela de a îmbrățișa flexibilitatea acolo unde poți. Dacă înțelegeți intenția și rigoarea controalelor la care v-ați aștepta și un furnizor de servicii se întâmplă să îndeplinească aceeași intenție la același nivel de rigoare, dar într-un mod diferit decât vă așteptați, oferind opțiuni pentru furnizorul de servicii (altele decât necesitatea să cumpere și să instaleze controale de care nu au nevoie) este util.

Din nou, niciunul dintre aceste sfaturi nu este știință despre rachete, desigur. Dar doar pentru că este evident nu înseamnă că toată lumea o face. Făcând câteva lucruri înainte de timp și privind printr-o lentilă empatică, puteți simplifica procesul de evaluare într-o situație ca aceasta.



Ed Moyle, partener la
Curba de securitate, este columnist al ECT News Network din 2007. Experiența sa extinsă în securitatea computerelor include experiență în criminalistică, teste de penetrare a aplicațiilor, audit de securitate a informațiilor și dezvoltare de soluții sigure. Ed este co-autor al Biblioteci criptografice pentru dezvoltatori și un colaborator frecvent la industria securității informațiilor ca autor, vorbitor public și analist.

.



Cititi mai mult pe technewsworld.com

Lasă un răspuns