Pe scurt: Managementul vulnerabilităților în întreprinderile mijlocii și în IMM-uri este un ciclu simplu și recurent: cunoașteți sistemele, urmăriți avertizările în mod țintit, evaluați după risc, decideți, implementați și dovediți. Esențiale nu sunt uneltele scumpe, ci responsabilitățile clare și o prioritizare care ține seama de accesibilitate, date și situația atacurilor. PHP2Shell este un bun exemplu de exercițiu, deoarece în el apar toți pașii.
Sute de avertizări, puțin personal
În fiecare săptămână sunt publicate noi breșe de securitate, în sisteme de operare, limbaje de programare, aplicații și pluginuri. Un concern are o echipă pentru asta. O întreprindere mijlocie are adesea un responsabil IT, unul-doi administratori și mai mulți furnizori externi de servicii. Nimeni nu poate citi fiecare avertizare și nici nu trebuie.
Este nevoie de un filtru: care avertizări privesc sistemele noastre, care dintre ele sunt urgente și cine se ocupă de ele? Dacă acest filtru lipsește, se întâmplă unul dintre două lucruri. Fie totul este ignorat până se întâmplă ceva, fie fiecare avertizare provoacă agitație, iar cea cu adevărat critică se pierde în zgomot.
Ciclul managementului vulnerabilităților
Un proces viabil pentru IMM-uri poate fi descris în șase pași:
- Înregistrați ce rulează. Fără inventar nu există comparație. Ce site-uri, servere, versiuni de PHP și aplicații operați și unde? Cum reușiți, arată articolul Să știți ce rulează: inventarul tuturor site-urilor și serverelor.
- Urmăriți avertizările. Abonați-vă la câteva surse de încredere: avertizările BSI, anunțurile producătorilor software-ului dumneavoastră, paginile de securitate ale distribuției Linux, iar pentru PHP pagina principală php.net.
- Evaluați. Ne privește avertizarea? Dacă da, cât de urgentă este? Mai multe despre aceasta mai jos.
- Decideți. Remediați, protejați provizoriu, izolați sistemul sau asumați riscul în mod conștient. Cine are voie să decidă ce?
- Implementați. Instalați actualizarea, aplicați o măsură provizorie, angajați un furnizor de servicii.
- Dovediți și urmăriți. Este breșa cu adevărat închisă? Când va fi înlocuită o soluție provizorie?
După aceea, ciclul reîncepe. Apar sisteme noi, cele vechi dispar și sosesc avertizări noi.
La pasul 2 ajută o regulă simplă: mai bine câteva surse citite regulat decât multe citite ocazional. Pentru un mediu web tipic de întreprindere mijlocie sunt de obicei suficiente avertizările CERT-Bund de la BSI (CERT-ul guvernului german), anunțurile de securitate ale distribuției Linux utilizate, paginile producătorilor de CMS și de magazine online și pagina principală php.net. Stabiliți cine citește aceste surse și creați pentru asta o căsuță poștală comună sau un canal care să nu depindă de o singură persoană.
În completare, merită o privire din exterior. O scanare periodică a vulnerabilităților sistemelor accesibile public arată dacă software învechit sau servicii deschise inutil sunt vizibile. Ea nu înlocuiește nici inventarul, nici actualizările, dar scoate la iveală sisteme care nu figurează în nicio listă.
Evaluarea: ce vine primul
Scorul CVSS, o clasificare standardizată a gravității, este un bun punct de plecare. Pentru ordinea din propria firmă nu este însă suficient. Decid încă trei întrebări:
| Întrebare | Crește urgența | Scade urgența |
|---|---|---|
| Este sistemul accesibil din internet? | site public, magazin online, portal | doar intern, în spatele unui VPN |
| Este necesară autentificarea pentru a exploata breșa? | nu, neautentificat | da, doar pentru administratori |
| Ce date prelucrează sistemul? | date ale clienților, plăți, acces | conținut public fără conturi |
| Există rapoarte despre atacuri? | tentative de atac raportate | nu se cunosc tentative |
| Există o măsură provizorie? | nu | da, cu eficacitate dovedită |
PHP2Shell arată cum se îmbină acestea. Ambele breșe au un scor CVSS v4.0 de 9.2, permit executarea de cod fără autentificare și afectează servere web accesibile public. Cloudflare și Patchstack au raportat, potrivit presei, tentative de atac, iar BSI a încadrat situația la nivelul de avertizare 3. Măsurile provizorii de la php.net nu oferă în mod explicit o protecție completă. Toate întrebările indică în aceeași direcție: acționați imediat. Ce a recomandat concret BSI se află la Ce recomandă BSI în cazul PHP2Shell.
Decizia și documentarea
Nu orice breșă poate fi închisă imediat. Un sistem vechi rulează pe PHP 8.1, pentru care nu mai există actualizări oficiale (vezi PHP 8.1 și mai vechi: ce se aplică acum), o aplicație specializată nu suportă încă actualizarea. Atunci este nevoie de o decizie, iar aceasta nu aparține doar departamentului tehnic.
O notă de decizie bună conține sistemul afectat, breșa, evaluarea, opțiunea aleasă, măsurile provizorii, persoana responsabilă și o dată pentru o nouă verificare. Dacă un risc este asumat în mod conștient, decide conducerea, nu administratorul singur. Și OWASP Cheat Sheet privind gestionarea dependențelor vulnerabile recomandă ca acceptarea riscului să fie ancorată în mod explicit la nivelul conducerii.
Păstrați o singură listă a vulnerabilităților deschise, cu stare, responsabil și termen. Un tabel este suficient. Important este ca lista să fie parcursă regulat, de exemplu în ședința lunară cu conducerea.
Ce legătură au NIS2 și furnizorii de servicii
Pentru companiile care intră sub incidența NIS2, gestionarea vulnerabilităților face parte din obligațiile de management al riscurilor. Detaliile le descrie NIS2 și securitatea serverelor web. Dar și fără obligație legală, un proces documentat este un avantaj, de pildă față de clienți, asigurători și propria conducere.
Mulți pași pot fi externalizați, de exemplu urmărirea avertizărilor sau instalarea actualizărilor. Decizia privind riscurile și imaginea de ansamblu ar trebui însă să rămână în firmă. Cine predă ciclul integral unui furnizor de servicii nu mai știe, în caz de urgență, nici măcar ce sisteme are. Cum se organizează implementarea ca rutină descrie Managementul patch-urilor ca proces, nu ca intervenție de urgență.
Cum ajută PHP SOS concret?
- Alcătuim împreună cu dumneavoastră inventarul site-urilor și serverelor, ca bază pentru orice comparație.
- Urmărim pentru sistemele dumneavoastră avertizările relevante și oferim o evaluare în cuvinte clare, cu recomandare.
- Pregătim note de decizie pentru situațiile în care o actualizare nu este posibilă imediat.
- Prin monitorizarea de securitate verificăm continuu dacă sistemele devin suspecte cât timp o breșă este încă deschisă.
Concluzie: Managementul vulnerabilităților în întreprinderile mijlocii nu trebuie să fie mare, ci obligatoriu. Cine își cunoaște sistemele, citește câteva surse bune și consemnează deciziile reacționează rapid și corect la următoarea avertizare critică.
Întrebări frecvente
Ce este managementul vulnerabilităților?
Un proces recurent prin care o companie află despre breșele de securitate din sistemele sale, le evaluează, le remediază sau le acceptă în mod conștient și consemnează rezultatul. Nu este vorba despre o unealtă, ci despre responsabilități și decizii.
Este suficient scorul CVSS pentru prioritizare?
Este un bun punct de plecare, dar nu este suficient. În plus contează dacă sistemul afectat este accesibil din internet, ce date prelucrează și dacă atacurile sunt deja observate. O vulnerabilitate cu scor ridicat pe un sistem intern de test poate aștepta, una pe magazinul online nu.
Are o firmă mică nevoie de o unealtă proprie pentru asta?
La început nu. Sunt suficiente o listă actualizată a sistemelor, avertizări de securitate abonate și un tabel cu punctele deschise. Scanerele de vulnerabilități merită folosite atunci când numărul sistemelor crește sau când verificările trebuie dovedite periodic.
Este permis să nu remediezi în mod conștient o vulnerabilitate?
Da, dacă riscul este evaluat, decizia este luată de conducerea responsabilă și consemnată în scris, ideal împreună cu măsuri provizorii și o dată pentru o nouă verificare.