Na kratko: Upravljanje ranljivosti v srednje velikih podjetjih in MSP je vitek, ponavljajoč se krog: poznati sisteme, ciljno spremljati obvestila, ocenjevati po tveganju, odločati, izvajati in dokazovati. Odločilna niso draga orodja, ampak jasne pristojnosti in določanje prednosti, ki upošteva dosegljivost, podatke in stanje napadov. PHP2Shell je dober vajeniški primer, ker se v njem pojavijo vsi koraki.
Na stotine obvestil, malo osebja
Vsak teden so objavljene nove varnostne vrzeli v operacijskih sistemih, programskih jezikih, aplikacijah in vtičnikih. Koncern ima za to ekipo. Srednje veliko podjetje ima pogosto vodjo IT, enega ali dva skrbnika in več zunanjih ponudnikov. Nihče ne more prebrati vsakega obvestila in tudi ni treba.
Potrebujemo filter: katera obvestila zadevajo naše sisteme, katera so med njimi nujna in kdo poskrbi zanje? Če filtra ni, se zgodi eno od dvojega. Ali se vse ignorira, dokler se kaj ne zgodi, ali vsako obvestilo sproži vznemirjenje in resnično kritično utone v šumu.
Krog upravljanja ranljivosti
Nosilen postopek za MSP je mogoče opisati v šestih korakih:
- Zabeležite, kaj teče. Brez popisa ni primerjave. Katere spletne strani, strežnike, različice PHP in aplikacije upravljate in kje? Kako to uspe, prikazuje prispevek Vedeti, kaj teče: popis vseh spletnih strani in strežnikov.
- Spremljajte obvestila. Naročite se na nekaj zanesljivih virov: opozorila BSI, obvestila proizvajalcev vaše programske opreme, varnostne strani vaše distribucije Linux, pri PHP naslovnico php.net.
- Ocenite. Ali nas obvestilo zadeva? Če da, kako nujno? Več spodaj.
- Odločite. Odpraviti, začasno zavarovati, izolirati sistem ali zavestno nositi tveganje. Kdo sme kaj odločati?
- Izvedite. Namestiti posodobitev, uvesti prehodni ukrep, naročiti ponudnika.
- Dokažite in spremljajte. Je vrzel res zaprta? Kdaj bo prehodna rešitev nadomeščena?
Nato se krog začne znova. Novi sistemi se dodajo, stari odpadejo in izidejo nova obvestila.
Pri koraku 2 pomaga preprosto pravilo: raje redno brati nekaj virov kot občasno veliko. Za značilno spletno okolje srednje velikega podjetja običajno zadoščajo opozorila CERT-Bund pri BSI (nemški vladni CERT), varnostna obvestila uporabljene distribucije Linux, strani proizvajalcev CMS in spletnih trgovin ter naslovnica php.net. Določite, kdo te vire bere, in zanje uredite skupni nabiralnik ali kanal, ki ni odvisen od posameznika.
Dopolnilno se splača pogled od zunaj. Redno skeniranje ranljivosti javno dosegljivih sistemov pokaže, ali sta vidna zastarela programska oprema ali po nepotrebnem odprte storitve. Ne nadomešča ne popisa ne posodobitev, odkrije pa sisteme, ki niso na nobenem seznamu.
Ocena: kaj pride prej na vrsto
Vrednost CVSS, standardizirana ocena resnosti, je dobro izhodišče. Za vrstni red v lastni hiši pa ne zadošča. Odločajo še tri vprašanja:
| Vprašanje | Povečuje nujnost | Zmanjšuje nujnost |
|---|---|---|
| Ali je sistem dosegljiv z interneta? | javna spletna stran, trgovina, portal | samo notranje, za VPN |
| Ali je za izkoriščanje vrzeli potrebna prijava? | ne, brez overitve | da, samo za skrbnike |
| Katere podatke sistem obdeluje? | podatki strank, plačila, dostopi | javne vsebine brez računov |
| Ali obstajajo poročila o napadih? | prijavljeni poskusi napadov | ni znanih poskusov |
| Ali obstaja prehodni ukrep? | ne | da, z dokazanim učinkom |
PHP2Shell kaže, kako to deluje skupaj. Obe vrzeli imata vrednost CVSS v4.0 9.2, omogočata izvajanje kode brez prijave in zadevata javno dosegljive spletne strežnike. Cloudflare in Patchstack sta po poročanju medijev poročala o poskusih napadov, BSI je stanje uvrstil v opozorilno stopnjo 3. Prehodni ukrepi php.net izrecno ne nudijo popolne zaščite. Vsa vprašanja kažejo v isto smer: ukrepajte takoj. Kaj je BSI konkretno priporočil, je na strani Kaj BSI priporoča glede PHP2Shell.
Odločanje in dokumentiranje
Vsake vrzeli ni mogoče zapreti takoj. Stari sistem teče na PHP 8.1, za katerega ni več uradnih posodobitev (glejte PHP 8.1 in starejši: kaj velja zdaj), strokovna aplikacija posodobitve še ne prenese. Tedaj je potrebna odločitev in ta ne sodi samo v tehniko.
Dobra beležka o odločitvi vsebuje prizadeti sistem, vrzel, oceno, izbrano možnost, prehodne ukrepe, odgovorno osebo in rok za ponovni pregled. Če se tveganje zavestno nosi, odloča vodstvo, ne skrbnik sam. Tudi OWASP Cheat Sheet o ravnanju z ranljivimi odvisnostmi priporoča, da se sprejetje tveganja izrecno uveljavi na ravni vodstva.
Vodite en sam seznam odprtih ranljivosti s statusom, odgovorno osebo in rokom. Zadošča preglednica. Pomembno je, da se redno pregleduje, na primer na mesečnem sestanku z vodstvom.
Kaj imata s tem NIS2 in ponudniki
Za podjetja, ki spadajo pod NIS2, je ravnanje z ranljivostmi del obveznosti upravljanja tveganj. Podrobnosti opisuje NIS2 in varnost spletnih strežnikov. A tudi brez zakonske obveznosti je dokumentiran postopek prednost, na primer v odnosu do strank, zavarovalnic in lastnega vodstva.
Mnoge korake je mogoče oddati zunanjim izvajalcem, na primer spremljanje obvestil ali nameščanje posodobitev. Odločitev o tveganjih in celoten pregled pa naj ostaneta v hiši. Kdor krog v celoti preda ponudniku, v skrajnem primeru ne ve več, kakšne sisteme sploh ima. Kako izvedbo organizirati kot rutino, opisuje Upravljanje popravkov kot proces namesto gasilske akcije.
Kako PHP SOS pomaga konkretno?
- Z vami izdelamo popis vaših spletnih strani in strežnikov kot podlago za vsako primerjavo.
- Za vaše sisteme spremljamo ustrezna obvestila in zagotovimo oceno v jasnih besedah s priporočilom.
- Pripravimo beležke o odločitvah za primere, ko posodobitev ni takoj mogoča.
- Prek nadzora varnosti sproti preverjamo, ali sistemi postanejo sumljivi, dokler je vrzel še odprta.
Sklep: Upravljanje ranljivosti v srednje velikih podjetjih ne sme biti veliko, mora pa biti zavezujoče. Kdor pozna svoje sisteme, bere nekaj dobrih virov in zapisuje odločitve, ob naslednjem kritičnem obvestilu odzove hitro in pravilno.
Pogosta vprašanja
Kaj je upravljanje ranljivosti?
Ponavljajoč se postopek, s katerim podjetje izve za varnostne vrzeli v svojih sistemih, jih oceni, odpravi ali zavestno sprejme in rezultat zapiše. Ne gre za orodje, ampak za pristojnosti in odločitve.
Ali za določanje prednostnega vrstnega reda zadošča vrednost CVSS?
Je dobro izhodišče, vendar ne zadošča. Odločilno je tudi, ali je prizadeti sistem dosegljiv z interneta, katere podatke obdeluje in ali so napadi že opaženi. Vrzel z visoko vrednostjo na notranjem testnem sistemu lahko počaka, vrzel v spletni trgovini ne.
Ali majhno podjetje za to potrebuje lastno orodje?
Za začetek ne. Zadoščajo vzdrževan seznam sistemov, naročena varnostna obvestila in preglednica z odprtimi točkami. Pregledovalniki ranljivosti se izplačajo, ko število sistemov raste ali je treba preglede redno dokazovati.
Ali smem ranljivost zavestno pustiti neodpravljeno?
Da, če je tveganje ocenjeno, odločitev sprejme pristojno vodstvo in je zapisana, najbolje s prehodnimi ukrepi in rokom za ponovni pregled.