Zero Trust Full

Hack-ul SolarWinds și fluxul constant de dezvăluiri despre instrumentele și tacticile utilizate sunt un bun studiu de caz chiar dacă a trecut mai bine de un an de la eveniment (plus că atacatorii au avut și alte ținte).

Ceea ce atrage atenția asupra subiectului nostru (Zero Trust) este implicarea lui Greg Touhill, președintele Grupului Federal Appgate, care a afirmat că el nu a fost surprins de evenimentul SolarWinds ci doar dezamăgit.

Acesta era deja total implicat în strategia Zero Trust și era extrem de preocupat de integritatea lanțului de aprovizionare al produselor și serviciilor firmei unde activa.

Ce este important de reținut este că acesta, împreună cu grupul său de lucru, identificase numeroase riscuri pentru lanțul de aprovizionare existent, în special din punct de vedere al inserției unui malware/backdoor la nivelul unui furnizor (deci, entitate externă, cu anumite prezențe în politicile de securitate cibernetică).

Chiar s-a prognozat riscul ca un actor de amenințare să pătrundă în ciclul de viață al dezvoltării software al unui furnizor și să introducă deliberat un backdoor.

Deci, discutăm despre o adevărată prezență în rețeaua existentă, fără a mai lua în calcul și alte organizații ce au fost lovite de atacatori (indiferent dacă aceștia au folosit sau nu platforma SolarWinds).

Dar să vedem cum au decurs evenimentele, pentru a înțelege procesele în ansamblu...

Cercetătorii de la Crowdstrike au documentat Sunspot, un program malware folosit de atacatorii SolarWinds, pentru a introduce malware-ul Sunburst în software-ul companiei.

SolarWinds a dezvăluit, de asemenea, o nouă cronologie pentru incident și descoperirea a două incidente de asistență pentru clienți despre care se consideră că ar putea fi legate de malware-ul Sunburst care era implementat pe infrastructura clienților-ul.

În care investigațiile nu au determinat și nici nu s-a identificat prezența codului rău intenționat Sunburst, în momente în care atacatorii testau operațiile și codurile lor.

Apoi, cercetătorii de la Karpersky Lab au descoperit mai multe asemănări între malware Sunburst și un backdoor .NET (Kazuar) raportat pentru prima dată de Palo Alto în 2017, legat de grupul Turla APT (care se crede că este sponsorizat de statul rus).

Cronologia atacului platformei Orion a SolarWinds spune totul...

04.09.2019 – Actorul de amenințare (TA – Threat Actor) accesează SolarWinds;

12.09.2019 – TA injectează codul de test și începe testele de rulare;

04.11.2019 – Finalizarea testării codului injectat;

20.02.2020 – Sunburst este compilat și descărcat;

26.03.2020 – Hotfix-ul și .dll-ul disponibil pentru clienți;

04.05.2020 – TA elimină malware-ul din VM-urile (mașinile virtuale) construite;

12.12.2020 – SolarWinds este notificat de Sunburst;

14.12.2020 – Fișiere SWI 8-K și notificarea acționarilor și clienților;

15.12.2020 – SWI realizează fix-ul software;

17.12.2020 – Este lansată alerta US-CERT ... Și totul a continuat...

Deci, avem de a face cu o prezență îndelungată, bine structurată de tip APT (Advanced Persistence Threat). Pentru cunoscători, procesul este aproape imposibil de identificat (ceea ce justifică această analiză pentru susținerea Zero Trust)...

“Când Sunspot găsește un proces MsBuild.exe (parte de instrumentelor de dezvoltare Microsoft Visual Studio), va apare o instanță pentru a determina dacă software-ul Orion este în curs de construire și, dacă da, va deturna operațiunea de construire pentru a o deturna și a injecta Sunburst. Bucla de monitorizare se execută în fiecare secundă, permițând Sunspot să modifice codul sursă țintă înainte ca acesta să fie citit de compilator”.

Interesantă este suprapunerea dintre Kazuar și Sunburst care folosesc același algoritm pentru a calcula timpul în care malware-ul rămâne latent până la realizarea unei noi conexiuni la server, același algoritm de hashing pentru obfuscarea șirurilor și același algoritm pentru generarea identificatorilor unici de victimă.

La fel se pare că este și în cazul actualului Cobalt Strike care se pare că are o origine de dezvoltare cu aceeași inițializare.

Deci, este destul de clar că avem de a face cu aceleași persoane care au dezvoltat în timp malware-ul inițial sau sunt persoane care s-au inspirat și au realizat dezvoltarea.

Cercetătorii au împărtășit și o serie de tactici, tehnici și proceduri (TTP – Tactics, Technics and Procedures) folosite de atacatori pentru a asigura persistența malware-ului, pentru a se asigura că manipularea codului nu va provoca erori de compilare și pentru a minimiza posibilitatea ca SolarWinds să le detecteze prezența și acțiunile.

Și Touhill a considerat că implementarea unui model de securitate Zero Trust este esențială, pentru a proteja mai bine datele, reputația și misiunea împotriva tuturor tipurilor de atacatori.

Dar de data aceasta începe confuzia în ceea ce privește arhitectura Zero Trust.

Cu toate că implementarea Zero Trust este un bun început se recomandă implementarea celor mai bune strategii/ tehnologii moderne de securitate, cum ar fi perimetru definit prin software (SDP – Software Defined Perimeter), autorizarea unui singur pachet (SPA – Single Packet Authorization), microsegmentarea, DMARC (pentru e-mail), gestionarea identității și a accesului (IDAM – Identity and Access Management) și altele.

Aceste prime decizii țin, la prima vedere, de vechile tehnici și strategii de securitate cibernetică. Dar, oare, așa este?

Zero Trust este doar o strategie, nimic altceva, care în mod evident se sprijină pe vechile tehnici/ practici dar capătă consecvență doar prin intermediul politicilor și a eforturilor ulterioare de identificare și acțiune permanentă.

În cazul exemplului nostru, abordarea SDP, de exemplu, era indicată deoarece aceasta este o tehnologie eficientă și sigură pentru accesul securizat de la distanță. Acces din ce în ce mai apelat pe măsură ce mediul tradițional de lucru la birou pivotează spre mediul general, spre lucrul de oriunde (pe motive de eficiență, pandemice, etc).

Apoi, tehnologia rețelei virtuale (VPN), care a fost tehnologia inițială pentru accesul securizat de la distanță, se dovedește din ce în ce mai fragilă, atacată cu succes din ce în ce mai frecvent (fie și datorită vechimii acesteia de peste 20 de ani).

La toate acestea se adaugă explozia de risc BYOD care apare ca o necesitate a adaptabilității noilor structuri de lucru.

Apoi au apărut problemele legate de imposibilitatea configurării complete a dispozitivelor folosite de membrii la respectivele rețele, problemele apărute de dispozitivele și/ sau sistemele de operare mai vechi, etc.

Și ar mai fi multe de spus, dar săptămâna viitoare...

 

Bibliografie:

Investigația hack-ului SolarWinds dezvăluie un nou malware Sunspot - link.

Zero Trust: O soluție la mai multe probleme de securitate cibernetică – link.

Dorin M, 7 Ianuarie 2022

Logo Dorin M Wolf

 

Vă mulţumesc pentru vizită!

Oricând veţi considera că "merită" vă aştept cu aprecieri, comentarii sau donaţii în
contul RO95BRDE090SV31723640900 deschis la "BRD - Groupe Société Générale" S.A. România sau
donaţie prin Paypal (folosind butonul de mai jos).

sau pe Patreon (utilizând butonul de mai jos).

Become a Patron!
  • About the Author: Dorin M - Merticaru Dorin Nicolae

No thoughts on “Ce ar putea preveni ZTA (Zero Trust Architecture) – Studiu de caz.”