Vulnerabilitățile Log4j sunt aici pentru a rămâne — ești pregătit?

Vulnerabilitatea larg răspândită care a apărut pentru prima dată în Apache Log4j în 2021 va continua sa fie exploatat, posibil chiar în moduri mai rele decât am văzut până acum. Aspectul mai îngrijorător al acestor amenințări este că există șanse mari ca acestea să continue să fie exploatate luni sau ani în viitor.

Consiliul de evaluare a siguranței cibernetice a Departamentului pentru Securitate Internă a debutat în 2021, iar în 2022 și-a lansat raport inaugural de siguranță (PDF). În ea, consiliul a numit Log4j o „vulnerabilitate endemică”, în principal pentru că nu există o „listă cuprinzătoare de clienți” pentru Log4j, făcând ca ținerea pasului cu vulnerabilitățile să fie o sarcină aproape imposibilă. Un departament federal al Cabinetului a petrecut chiar și 33,000 de ore pentru răspunsul său Log4j.

Și multe organizații și soluții de securitate de pe piață nu reușesc să identifice diferența dintre exploatare și vulnerabilitate - lăsând atacatorilor posibilitatea de a desfășura activități rău intenționate.

Exploatabilitate vs. Vulnerabilitate

Una dintre problemele cheie ale securității cibernetice astăzi este înțelegerea diferenței dintre vulnerabilități și gravitatea acestora. Când vine vorba de măsurarea exploatării în comparație cu o vulnerabilitate, există o mare diferență între dacă o amenințare de securitate este exploatabilă în cadrul afacerii dvs. sau dacă este doar „vulnerabilă” și nu poate împiedica afacerea sau atinge un activ critic. Echipele de securitate petrec prea mult timp neînțelegând diferența dintre cele două și remediază fiecare vulnerabilitate așa cum apare, în loc să le acorde prioritate celor care sunt exploatabile.

Fiecare companie are mii de vulnerabilități și expuneri comune (CVE), dintre care multe au un punctaj ridicat la Sistemul comun de punctare a vulnerabilităților (CVSS), așa că este imposibil să le remediezi pe toate. Pentru a combate acest lucru, speranța este că instrumentele de management al vulnerabilităților bazate pe riscuri (RBVM) vor face acest lucru ușurează stabilirea priorităților prin clarificarea a ceea ce este exploatabil.

Cu toate acestea, abordările de prioritizare a securității care combină scorurile CVSS cu informații despre amenințări RBVM nu oferă rezultate optime. Chiar și după filtrarea și analizarea a ceea ce este exploatabil în sălbăticie, echipele de securitate au încă prea multe de gestionat, deoarece lista este lungă și de negestionat. Și doar pentru că un CVE nu are un exploit astăzi, nu înseamnă că nu va avea unul săptămâna viitoare.

Ca răspuns, companiile au adăugat AI cu risc predictiv, care poate ajuta utilizatorii să înțeleagă dacă un CVE ar putea fi exploatat în viitor. Acest lucru încă nu este suficient și duce la prea multe probleme de rezolvat. Mii de vulnerabilități vor avea în continuare un exploit, dar multe vor avea alte seturi de condiții care trebuie îndeplinite pentru a exploata efectiv problema.

De exemplu, cu Log4j, trebuie identificați următorii parametri:

• Există biblioteca vulnerabilă Log4j?
• Este încărcat de o aplicație Java care rulează?
• Este activată căutarea JNDI?
• Ascultă Java conexiuni la distanță și există o conexiune pentru alte mașini?

Dacă condițiile și parametrii nu sunt îndepliniți, vulnerabilitatea nu este critică și nu ar trebui să fie prioritizată. Și chiar dacă o vulnerabilitate ar putea fi exploatabilă pe o mașină, deci ce? Este acea mașină extrem de critică sau poate nu este conectată la niciun activ critic sau sensibil?

De asemenea, este posibil ca mașina să nu fie importantă, dar poate permite unui atacator să continue spre activele critice în moduri mai ascunse. Cu alte cuvinte, contextul este cheia – această vulnerabilitate se află pe o cale potențială de atac către activul critic? Este suficient să tăiați o vulnerabilitate la un punct de sufocare (o intersecție a mai multor căi de atac) pentru a opri calea de atac să ajungă la un activ critic?

Echipele de securitate urăsc procesele de vulnerabilitate și soluțiile lor, pentru că există tot mai multe vulnerabilități - nimeni nu poate șterge niciodată complet. Dar dacă pot concentrați-vă pe ceea ce poate crea prejudiciu la un activ critic, ei pot înțelege mai bine de unde să înceapă.

Combaterea vulnerabilităților Log4j

Vestea bună este că gestionarea adecvată a vulnerabilităților poate ajuta la reducerea și remedierea expunerii la atacurile centrate pe Log4j, identificând unde există riscul potențialului de exploatare.

Managementul vulnerabilităților este un aspect important al securității cibernetice și este necesar pentru asigurarea securității și integrității sistemelor și datelor. Cu toate acestea, nu este un proces perfect, iar vulnerabilitățile pot fi încă prezente în sisteme, în ciuda celor mai bune eforturi de a le identifica și atenua. Este important să revizuiți și să actualizați în mod regulat procesele și strategiile de gestionare a vulnerabilităților pentru a vă asigura că acestea sunt eficiente și că vulnerabilitățile sunt abordate în timp util.

Accentul managementului vulnerabilităților nu ar trebui să fie doar pe vulnerabilitățile în sine, ci și pe riscul potențial de exploatare. Este important să identificați punctele în care un atacator ar putea să fi obținut acces la rețea, precum și căile pe care le-ar putea lua pentru a compromite activele critice. Cea mai eficientă și mai rentabilă modalitate de a atenua riscurile unei anumite vulnerabilități este de a identifica conexiunile dintre vulnerabilități, configurări greșite și comportamentul utilizatorului care ar putea fi exploatate de un atacator și de a aborda în mod proactiv aceste probleme înainte ca vulnerabilitatea să fie exploatată. Acest lucru poate ajuta la întreruperea atacului și la prevenirea deteriorarii sistemului.

De asemenea, ar trebui să faceți următoarele:

• Plasture: Identificați toate produsele dvs. care sunt vulnerabile la Log4j. Acest lucru se poate face manual sau folosind scanere open source. Dacă este lansat un patch relevant pentru unul dintre produsele dumneavoastră vulnerabile, corecționați sistemul cât mai curând posibil.
• Soluţia: Pe Log4j versiunile 2.10.0 și mai sus, în linia Java CMD, setați următoarele: log4j2.formatMsgNoLookups=true
• Bloc: Dacă este posibil, adăugați o regulă la firewall-ul aplicației Web pentru a bloca: „jndi:”

Securitatea perfectă este o ispravă de nerealizat, așa că nu are sens să facem perfect inamicul binelui. În schimb, concentrați-vă pe prioritizarea și blocarea potențialelor căi de atac care îmbunătățesc continuu postura de securitate. Identificarea și a fi realist cu privire la ceea ce este de fapt vulnerabil față de ceea ce este exploatabil poate ajuta la acest lucru, deoarece va permite capacitatea de a direcționa strategic resursele către zonele critice care contează cel mai mult.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
• Sursa: https://www.darkreading.com/attacks-breaches/log4j-vulnerabilities-are-here-to-stay-are-you-prepared-