Stručne: Riadenie zraniteľností v strednej veľkosti firiem a v MSP je štíhly, opakujúci sa cyklus: poznať systémy, cielene sledovať hlásenia, hodnotiť podľa rizika, rozhodnúť, zrealizovať a doložiť. Rozhodujúce nie sú drahé nástroje, ale jasné zodpovednosti a stanovenie priorít, ktoré zohľadňuje dostupnosť, údaje a situáciu v útokoch. PHP2Shell je dobrý cvičný príklad, pretože sa v ňom vyskytujú všetky kroky.
Stovky hlásení, málo ľudí
Každý týždeň sa zverejnia nové bezpečnostné diery v operačných systémoch, programovacích jazykoch, aplikáciách a pluginoch. Koncern na to má tím. Stredná firma má často vedúceho IT, jedného alebo dvoch administrátorov a viacerých externých dodávateľov. Nikto nedokáže prečítať každé hlásenie a nikto to ani nemusí.
Potrebný je filter: Ktoré hlásenia sa týkajú našich systémov, ktoré z nich sú naliehavé a kto sa o ne postará? Ak tento filter chýba, nastane jedno z dvoch. Buď sa všetko ignoruje, kým sa niečo nestane, alebo každé hlásenie vyvolá rozruch a skutočne kritické zanikne v šume.
Cyklus riadenia zraniteľností
Použiteľný postup pre MSP sa dá opísať v šiestich krokoch:
- Zistiť, čo beží. Bez inventára nie je čo porovnávať. Aké weby, servery, verzie PHP a aplikácie prevádzkujete a kde? Ako sa to podarí, ukazuje článok Vedieť, čo beží: inventár všetkých webov a serverov.
- Sledovať hlásenia. Odoberať niekoľko spoľahlivých zdrojov: varovania BSI (nemecký Spolkový úrad pre informačnú bezpečnosť), hlásenia výrobcov vášho softvéru, bezpečnostné stránky vašej linuxovej distribúcie a pri PHP úvodnú stránku php.net.
- Hodnotiť. Týka sa hlásenie nás? Ak áno, aké je naliehavé? Viac nižšie.
- Rozhodnúť. Odstrániť, dočasne zabezpečiť, systém izolovať alebo riziko vedome znášať. Kto o čom smie rozhodovať?
- Zrealizovať. Nainštalovať aktualizáciu, nastaviť prechodné opatrenie, poveriť dodávateľa.
- Doložiť a sledovať. Je zraniteľnosť naozaj uzavretá? Kedy sa prechodné riešenie nahradí?
Potom cyklus začína odznova. Pribúdajú nové systémy, staré zanikajú a objavujú sa nové hlásenia.
Pri kroku 2 pomáha jednoduché pravidlo: radšej pravidelne čítať niekoľko zdrojov než príležitostne veľa. Pre typické webové prostredie strednej firmy zvyčajne stačia varovné správy CERT-Bund (tím nemeckej vlády pre reakcie na počítačové núdzové situácie) pri BSI, bezpečnostné hlásenia používanej linuxovej distribúcie, stránky výrobcov CMS a obchodných systémov a úvodná stránka php.net. Určte, kto tieto zdroje číta, a zriaďte na to spoločnú schránku alebo kanál, ktorý nezávisí od jednej osoby.
Zmysel má aj pohľad zvonku. Pravidelný sken zraniteľností verejne dostupných systémov ukáže, či sú viditeľné zastarané programy alebo zbytočne otvorené služby. Nenahrádza inventár ani aktualizácie, ale odhalí systémy, ktoré nie sú v žiadnom zozname.
Hodnotiť: čo príde na rad ako prvé
Hodnota CVSS, štandardizované zaradenie závažnosti, je dobrý východiskový bod. Na poradie vo vlastnej firme však nestačí. Rozhodujú tri ďalšie otázky:
| Otázka | Zvyšuje naliehavosť | Znižuje naliehavosť |
|---|---|---|
| Je systém dostupný z internetu? | verejný web, obchod, portál | iba interne, za VPN |
| Je na zneužitie zraniteľnosti potrebné prihlásenie? | nie, bez overenia | áno, iba pre administrátorov |
| Aké údaje systém spracúva? | zákaznícke údaje, platby, prístupy | verejný obsah bez účtov |
| Existujú správy o útokoch? | hlásené pokusy o útok | žiadne známe pokusy |
| Existuje prechodné opatrenie? | nie | áno, s doloženým účinkom |
PHP2Shell ukazuje, ako to spolu funguje. Obe zraniteľnosti majú hodnotu CVSS v4.0 9.2, umožňujú spustenie kódu bez prihlásenia a týkajú sa verejne dostupných webových serverov. Cloudflare a Patchstack podľa médií hlásili pokusy o útok, BSI zaradilo situáciu do stupňa varovania 3. Prechodné opatrenia od php.net výslovne neposkytujú úplnú ochranu. Všetky otázky smerujú rovnakým smerom: konať okamžite. Čo BSI konkrétne odporučilo, nájdete v článku Čo BSI k PHP2Shell odporúča.
Rozhodnúť a zdokumentovať
Nie každú zraniteľnosť sa dá okamžite uzavrieť. Starý systém beží na PHP 8.1, pre ktoré už neexistujú oficiálne aktualizácie (pozri PHP 8.1 a staršie: čo platí teraz), odborná aplikácia zatiaľ aktualizáciu nezvláda. Vtedy je potrebné rozhodnutie a to nepatrí iba do techniky.
Dobrá poznámka k rozhodnutiu obsahuje dotknutý systém, zraniteľnosť, hodnotenie, zvolenú možnosť, prechodné opatrenia, zodpovednú osobu a termín opätovného preskúmania. Ak sa riziko vedome znáša, rozhoduje vedenie a nie samotný administrátor. OWASP Cheat Sheet k nakladaniu so zraniteľnými závislosťami tiež odporúča výslovne ukotviť akceptáciu rizika na úrovni vedenia.
Veďte jediný zoznam otvorených zraniteľností so stavom, zodpovednou osobou a termínom. Stačí tabuľka. Dôležité je, aby sa pravidelne prechádzala, napríklad na mesačnom stretnutí s konateľmi.
Čo s tým majú spoločné NIS2 a dodávatelia
Pre firmy, na ktoré sa vzťahuje NIS2, je nakladanie so zraniteľnosťami súčasťou povinností v oblasti riadenia rizík. Podrobnosti opisuje článok NIS2 a bezpečnosť webservera. Aj bez zákonnej povinnosti je však zdokumentovaný postup výhodou, napríklad voči zákazníkom, poisťovateľom a vlastnému vedeniu.
Mnohé kroky sa dajú outsourcovať, napríklad sledovanie hlásení alebo inštalácia aktualizácií. Rozhodnutie o rizikách a celkový prehľad by však mali zostať vo firme. Kto cyklus úplne odovzdá dodávateľovi, v krízovom prípade už nevie, aké systémy vôbec má. Ako sa realizácia organizuje ako rutina, opisuje článok Správa záplat ako proces namiesto hasenia požiarov.
Ako konkrétne pomáha PHP SOS?
- Spolu s vami vypracujeme inventár vašich webov a serverov ako základ každého porovnania.
- Pre vaše systémy sledujeme relevantné hlásenia a dodávame hodnotenie jasnými slovami s odporúčaním.
- Pripravujeme poznámky k rozhodnutiam pre prípady, keď aktualizácia nie je možná okamžite.
- Prostredníctvom security monitoringu priebežne kontrolujeme, či sa systémy nestávajú nápadnými, kým je zraniteľnosť ešte otvorená.
Záver: Riadenie zraniteľností v strednej firme nemusí byť veľké, ale musí byť záväzné. Kto pozná svoje systémy, pravidelne číta niekoľko dobrých zdrojov a zapisuje rozhodnutia, zareaguje pri ďalšom kritickom hlásení rýchlo a správne.
Časté otázky
Čo je riadenie zraniteľností?
Opakujúci sa postup, ktorým sa firma dozvedá o bezpečnostných dierach vo svojich systémoch, hodnotí ich, odstraňuje ich alebo vedome akceptuje a výsledok zaznamenáva. Nejde o nástroj, ale o zodpovednosti a rozhodnutia.
Stačí na stanovenie priorít hodnota CVSS?
Je to dobrý východiskový bod, ale nestačí. Rozhodujúce je navyše to, či je dotknutý systém dostupný z internetu, aké údaje spracúva a či sa útoky už pozorujú. Zraniteľnosť s vysokým hodnotením na internom testovacom systéme môže počkať, na obchode nie.
Potrebuje na to malá firma vlastný nástroj?
Na začiatku nie. Stačí udržiavaný zoznam systémov, odoberané bezpečnostné hlásenia a tabuľka s otvorenými bodmi. Skenery zraniteľností sa oplatia, keď počet systémov rastie alebo keď treba kontroly pravidelne dokladovať.
Smie sa zraniteľnosť vedome neodstrániť?
Áno, ak sa riziko posúdi, rozhodnutie urobí zodpovedné vedenie a zapíše sa, ideálne spolu s prechodnými opatreniami a termínom opätovného preskúmania.